On Fri, 14 Sep 2001 moran@galconn.com wrote: (snip)
Further clarification: the extension allows you to _raise_ exceptions in pure functions, but you may only catch them in the IO monad.
This asymmetry is very important for Haskell, since otherwise evaluation order would be observable. This would break many important equalities and render almost any optimizations unsafe (i.e., GHC would be crippled). ML allows one to catch exceptions in pure functions with impunity, and can do so because evaluation order is fixed. The story is similar for imperative languages. (snip)
For the sort of exception where the function you're calling either returns successfully or throws an exception, I'm not sure why things can't be done entirely referentially transparently. One would do it in just the same way that something might return a 'Succeeded a' or 'Exception String' or something as aspects of an algebraic data type. The function, whenever it does something that might cause an exception, if it gets a 'Succeeded a' returned it goes ahead and returns something based on the a, or else it returns the Exception String, except if there's a 'catch' which specifies some other value to return if there was an exception. Basically, such simple exceptions can have a 'try', 'catch' construct simply being syntactic sugar around existing Haskell using algebraic types, pattern matching and 'if' statements, so I don't see why monads need to be brought in. Evaluation is done exactly as usual - when you decide to do something predicated on whether or not there was an exception thrown, we evaluate enough to find out if an error condition happened. However, there is a lot I don't know about Haskell! I assume you're talking about some more exciting sort of exception, like things with multiple threads or something, and I'm thinking of something more simplistic (but adequate for my immediate needs, which are currently being served with lots of ifs and Maybes!). -- Mark