> Just to reiterate.  I strongly urge you to ensure consistent exception
> behavior.  As a matter of course, two different compiles should not result
> in two different programs. 

One of the wonderful things about functional languages is that they
do not prescribe the order of evaluation.  To achieve the effect you
want would require us to completely prescribe that order, with
very bad effects on efficiency.  For example, consider

        f :: [Int] -> Int

Suppose that an analyser figures out that f evaluates every
element of its argument list to produce its result.  Then it
is OK for the producer of the list to evaluate those thunks
right away, rather than building thunks for f to evaluate.

But if we are required to ensure consistent choice of exception
values then we can't do that any more, because the producer
might evaluate the thunks in a different order to f.

This is a big issue for a lazy language.

I really think that the thing to do is leave it unspecified
which exception is chosen.  In practice, only changing the
compiler's optimisation level is likely to change the program's
exception behaviour.

Simon


> As a matter of course, should we assume that these extensions
> (exceptions, existentials) will become part of Haskell or are they just
> part GHC?  Will they be part of Hugs?

Hugs and GHC will be consistent.  Whether it's a feature deemed
worthy of being Officially Incorporated into Haskell is not
something we'll know for a while.  It's much more likely
to be so incorporated if its implemented and found useful, though.





Reply via email to