Tue, 10 Dec 2002 03:09:49 +1100
On 09-Dec-2002, Mark Carroll <email@example.com> wrote:
> On Sun, 8 Dec 2002, John Meacham wrote:
> > throw (userException "foo") + throw (userException "bar")
> > without defining an evaluation order you cannot know which exepction is
> > to be thrown. catching the exception in the IO monad makes this 'okay'
> Would it help if you defined an order over the possible exceptions, then
> if one is thrown you evaluate other parts of the expression to see if they
> also threw one, and return the "first" according to the ordering?
That would be too expensive, and would still prevent many of the
kinds of optimizations that we'd like to allow, I think.
f :: Int -> Int
f = ...
x :: Int
x = a + b where b = f a
a = f 0
Suppose `f' is strict.
We'd like to implement `f' using some code which expects the arguments
to be already evaluated, and known to be non-exceptional values, so that
they can be passed directly in registers without any need for boxing.
We'd also like to implement `x' by code which evaluates `a = f 0', then
`b = f a', and finally `x = a + b'.
But with your proposed semantics, there is a problem with this approach.
If `a = f 0' throws an exception, then your proposed semantics
would mean that we need to still evaluate `b = f a' to see if that throws
an exception. But we don't have a (non-exceptional) value for `a'.
Fergus Henderson <firstname.lastname@example.org> | "I have always known that the pursuit
The University of Melbourne | of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.