Mike - I hope you don't mind passing this to the list - but it's a great, simple explanation of a big problem with my approach. On 14 Sep 2001, Mike Gunter wrote:

The problem is not a loss of referential transparency but the requirement that evaluation order must be specified. E.g. what should

raise "left" + raise "right"

return? (snip)

Ah! Yes, I see what you mean - this explains what Andy Moran was thinking, probably. (-: Moreover, if we have a pseudo-Haskell code snippet like, try f (a 1) (b 2) catch error-1 -> 1 error-2 -> 2 where a _ = raise error-1 b _ = raise error-2 ... then is the return value of this 1 or 2? AFAICS a simple way to get out of this is to only have one exception type that carries no information instead of different ones so we can't distinguish one exception from another, but that's obviously not great. One other thing you could do, which might mean a bit more evaluating than you otherwise would have done, is to evaluate enough to find out what the different possible "first exception"s are, gather them all up, and the handler that operates is the first applicable one if you list the higher-level 'catch' statements before the lower ones (so there's a total order on the handlers for exceptions arising from any particular expression within an evaluation). So, in this case, we detect that error-1 and error-2 were both thrown, but we return '1' because the error-1 handler was listed before the error-2 handler, just as we do with pattern matching IYSWIM. So, maybe we do have a way to resolve this that doesn't reveal evaluation order, with the penalty that we have to evaluate enough to discover which possible exceptions get thrown so that we really do use the 'first' applicable handler. I'm also subscribe to haskell-cafe if people think this discussion should migrate to there. -- Mark