[ Meant for this to go to the mailing list ... ] -- Andy Moran Ph. (503) 526 3472 Galois Connections Inc. Fax. (503) 350 0833 3875 SW Hall Blvd. http://www.galconn.com Beaverton, OR 97005 [EMAIL PROTECTED]
Mark Carroll wrote: > 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. Exceptions can be encoded in this way, and for a while this was the only way to have exceptions in Haskell (modulo monadic presentations, etc.). But what about division by zero? It can easily be encoded in the above style: Exception "Division by Zero". But now _every_ function that can raise or wants to handle this exception must be rewritten so that it either wraps correct results with Succeeded, wraps exceptional results with Exception, and passes exceptional results upwards. The point of the exceptions extension is that you don't need to change anything; existing code (even that which may cause a division by zero error) remains as it is. And we can raise exceptions of our own anywhere. The tradeoff is that we can catch these exceptions in the IO monad. But we can extend the extension to handle asychronous exceptions (which don't admit this kind of encoding, AFAIK). Cheers, Andy -- Andy Moran Ph. (503) 526 3472 Galois Connections Inc. Fax. (503) 350 0833 3875 SW Hall Blvd. http://www.galconn.com Beaverton, OR 97005 [EMAIL PROTECTED]