Tim Docker [EMAIL PROTECTED] writes:
Of course... that was my second alternative error strategy. I'm
interest in how/when people decide when to throw exceptions versus
when to thread errors using monads, given that changing code from
one to the other could be quite a big deal.
I generally
I'm finding that a recurring theme in my work with Haskell libraries (and
in particular the XML libraries) is the awkwardness of handling errors
outside the IO monad.
While it's often very easy to write some code that performs some function,
assuming that the inputs are valid, as soon as code
I can't see any fundamental reason why exception handling has to occur in
the IO monad.
Read the paper _A Semantics for Imprecise Exceptions_. The problem is that the
evaluation order of Haskell would have to be fixed for this not to lose referential
transparency. What is the value of
On Mon, 2004-06-14 at 14:34, Graham Klyne wrote:
I'm finding that a recurring theme in my work with Haskell libraries (and
in particular the XML libraries) is the awkwardness of handling errors
outside the IO monad.
With GHC You can throw exceptions in pure code but may only catch them
in
Keith Wansbrough wrote:
Read the paper _A Semantics for Imprecise Exceptions_. The
problem is that the evaluation order of Haskell would have to
be fixed for this not to lose referential transparency. What
is the value of
catchExcept (show (makeExcept E1 + makeExcept E2))
(\x - x)
On Mon, 14 Jun 2004, Keith Wansbrough wrote:
(snip)
to lose referential transparency. What is the value of
catchExcept (show (makeExcept E1 + makeExcept E2)) (\x - x)
? Haskell wouldn't be purely functional any more.
(snip)
We've already had these issues raised on haskell-cafe when I've
On Mon, 14 Jun 2004, Tim Docker wrote:
Both of these approaches seem fairly invasive in their
effect on the code. Are people using haskell for real world
tasks happy with having to choose from these? The former is
more general, but any function that needs to be able to
fail or propagate
Now I see it. Thanks.
Thanks also for the reference. Nice paper!
So now where do I stand?
I still think that being forced to handle exceptions in the IO monad is
(sometimes) inconvenient, but I can now see why it is required for a
rigorous language semantics. My problem relates to wanting to
Philippa Cowderoy wrote:
The ability to fail doesn't need the do notation, just use of
return for success - similar for propagating failure.
I'm not sure I understand. Do you mean writing functions
like:
sqr x | x 0 = fail less than zero
| otherwise = return (sqrt x)
If
Philippa Cowderoy wrote:
The ability to fail doesn't need the do notation, just use of
return for success - similar for propagating failure.
I'm not sure I understand. Do you mean writing functions
like:
sqr x | x 0 = fail less than zero
| otherwise = return
Keith Wansbrough wrote:
s/fail/error/
s/return//
Then you can easily write
I can't (easily) write
text c = sqr x + sqr (x+1)
You just can't *catch* this outside the IO monad.
Of course... that was my second alternative error
strategy. I'm interest in how/when people decide
I assume the suggested mapException function [sect 5.4] remains
unproblematic ... is it (or some equivalent) actually implemented?
http://etudiants.insia.org/~jbobbio/pafp/docs/base/Control.Exception.html#v%
3AmapException
The same page has a host of other useful operations.
Two useful
On Mon, Jun 14, 2004 at 05:41:03PM +0100, Keith Wansbrough wrote:
Philippa Cowderoy wrote:
The ability to fail doesn't need the do notation, just use of
return for success - similar for propagating failure.
I'm not sure I understand. Do you mean writing functions
like:
Graham Klyne writes:
Another approach that occurs to me is to introduce an error Monad
along the lines of that described by Philip Wadler as E in his
Essence of functional programming paper [1]. (Or just use Either
as an error monad?, which is part of what I've been doing with my XML
work.)
14 matches
Mail list logo