"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 gener
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
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
> >
> 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 cap
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 peo
> 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
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)
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 b
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 propagat
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 w
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"))
>
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
> 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
ca
13 matches
Mail list logo
