Error Handling

[Mark Carroll]

On 10 Dec 2002, Alastair Reid wrote:
(snip)
> To do this, we have to actually build the set of all exceptions that
> an expression could raise.  This could take quite a while to build

Why? I can see that, to do the ordering, you may want to know all the
exceptions that can arise somewhere in the program, not minding about a
few false positives. Then, at runtime, if an exception pops up, we just
evaluate the other "parallel" expressions to see what else happens. Even
if we do need the exact set of all exceptions that a particular expression
could raise, could that be found at compile time?

(snip)
> And even this wouldn't get rid of the monads since the problem monads
> deal with is present even if we can't observe the exceptions.  For
> example, a simple operation like this:
>
>   choose :: a -> a -> a
>
> which returns its first argument if it can evaluate its argument to
> WHNF without raising an exception and returns its 2nd argument
> otherwise has severe semantic problems.

I don't understand why, I'm afraid. I'm not sure if I'm missing something
obvious or if we're somehow talking at cross-purposes. It probably doesn't
help that I can imagine what it means to evaluate the first argument
strictly but I'm having difficulty figuring out what Weak Head Normal Form
is in relation to what Haskell code might get up to. I seem to have a
problem understanding exactly how mathematical things shore up practical
computing things even when I understand each in isolation, though.

Of course, I am happy to suspend judgment until I understand your point
better, and I don't think that you have any obligation to bring my
education to the point where I can understand it!

-- Mark