On 15-Sep-2001, Mark Carroll <mark@chaos.x-philes.com> 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 <fjh@cs.mu.oz.au> | "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.