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

[Marco Kesseler]

On Fri, 2004-01-30 at 11:08, Simon Marlow wrote: 
> > 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.

Currently, Clean has no functions with catch statements, so how can
there be fewer equivalences if the limitation applies to them?

> 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.

Why?

Exceptions do not exist until they arrive at a function that catches
them. I can take an existing function without any catch statements and
place some function around it that catches the exceptions that might
arise in it. And only THEN the exception gets transformed into a value.
The existing function does not notice this in any way.

If I do not introduce this exception catcher, the function will simply
lead to an abort when an exception arises, which is what happens now in
Clean.

> 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?

It would be, if it were true.

If I would have said that functions "+" and "-" are not equivalent, then
nobody would have found this weird. I am now saying that if you place a
catch statement inside a function that it will no longer be equivalent
to any other function. The same would  be true if I changed the function
body in other ways.

> 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.

It is possible that I did not express myself clear enough. But please
carefully reconsider what I wrote here, and in earlier messages. There
is no damage.

regards,
Marco