Application letters at the Haskell workshop: suggestion

[Mark Carroll]

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