On 15-Sep-2001, Mark Carroll <[EMAIL PROTECTED]> wrote:
> 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.
Unfortunately even that doesn't work, because there are still problems with
non-termination. Consider the following example:
try
f (a 1) (b 2)
catch
error-1 -> 1
where
a _ = raise error-1
b n = b n
Should this program return 1, or loop?
Giving this program deterministic behaviour requires specifying the order of
evaluation.
--
Fergus Henderson <[EMAIL PROTECTED]> | "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.
_______________________________________________
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell