[clean-list] exceptions again (a bit long, but this might actually be correct)

[Simon Marlow]

> First of all, the expression
> 
> (x + y)
> catch e = ...
> 
> does not exist as such. Instead, I propose that "catch" expression can
> only exist as part of a named function definition:
> 
> f x y
>   = (x + y)
>   catch e = v e x y
> 
> And yes: (f x y) may have a different value than (f y x). 
> This does not
> destroy commutativity of "+". f is not +.
> 
> Furthermore, the mere existence of the catch statement 
> implies that the
> f is NOT equivalent to for example:
> 
> g x y
>   = (y + x)
>   catch e = v e x y
> 
> and possibly, not even to
> 
> h x y
>   = (x + y)
>   catch e = v e x y
> 
> It is, as if the catch statement were parametrised with the entire
> function definition as text, including the function name.  For
> referential transparency, such a concept is no problem at all. It just
> limits equivalence for functions with catch statements.

"it just limits equivalence for functions with catch statements".  Let's
think about that:  you just admitted that your language has fewer
equivalences than before.  That's all I was trying to point out.

But I don't think you grasp the full impact of this change in the
language.  It applies not just to "functions with catch statements" as
you say, but all functions which are called by functions with catch
statements, and all functions called by them, and so on.

And in these parts of the program, the equivalence property between
expressions is far more limited than denotational equivalence - it is
more like "exact textual equality".  So, I guess you could say that your
language is still referentially transparent if you use "textual
equality" as the equivalence property, but that's far less useful than
denotational equality.  The compiler is severely limited in what
optimisations it can do, and programmers have much less scope for
equational reasoning.  Is this not a severe problem?

Your new proposal just attempts to limit the damage to "functions with
catch statements", whereas previously it applied to the entire program
(because of laziness).  However, it still applies to the dyanmic scope
of a catch statement, and hence potentially any part of the program.

Cheers,
	Simon