Application letters at the Haskell workshop: suggestion

[Mark Carroll]

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