Re: [Haskell] IO, exceptions and error handling

2004-06-15 Thread Ketil Malde
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

[Haskell] IO, exceptions and error handling

2004-06-14 Thread Graham Klyne
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

Re: [Haskell] IO, exceptions and error handling

2004-06-14 Thread Keith Wansbrough
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

Re: [Haskell] IO, exceptions and error handling

2004-06-14 Thread Duncan Coutts
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

RE: [Haskell] IO, exceptions and error handling

2004-06-14 Thread Tim Docker
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)

Re: [Haskell] IO, exceptions and error handling

2004-06-14 Thread Mark Carroll
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

RE: [Haskell] IO, exceptions and error handling

2004-06-14 Thread Philippa Cowderoy
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

Re: [Haskell] IO, exceptions and error handling

2004-06-14 Thread Graham Klyne
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

RE: [Haskell] IO, exceptions and error handling

2004-06-14 Thread Tim Docker
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

Re: [Haskell] IO, exceptions and error handling

2004-06-14 Thread Keith Wansbrough
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

RE: [Haskell] IO, exceptions and error handling

2004-06-14 Thread Tim Docker
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

Re: [Haskell] IO, exceptions and error handling

2004-06-14 Thread Alastair Reid
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

Re: [Haskell] IO, exceptions and error handling

2004-06-14 Thread John Meacham
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:

Re: [Haskell] IO, exceptions and error handling

2004-06-14 Thread David Menendez
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.)