[clean-list] Clean in the Real World

[Brent A. Fulgham]

On Saturday 13 December 2003 3:02 pm, Marco Kesseler wrote:
> A main issue in the paper seems to be - if you implement exceptions
> via stack trimming - that "getException (a + b)" may not have the
> same value as "getException (b + a)", if both a and b lead to an
> exceptional - but different - value. It depends on which one gets
> evaluated first, and often the compiler decides things for you.

[ ... snip ... ]

> And it is needless too. All it takes is a cheap syntactical change:
> do NOT pass the guarded expression as an argument to a function that
> checks for exceptions. Instead of getException(a + b) write:
>
> f a b
>     = a + b
>     catch e = ...
>
> g a b
>     = a + b
>     catch e = ...
>
> Now, catching the exception value has become decoupled from the (a +
> b) expression. Instead, it becomes associated with f and g.  And "f a
> b" does _not_ need to have the same value as "g a b", because f and g
> are different functions.

I have no quarrel with this approach -- in fact, it seems very similar to SML 
syntax (which might actually merge well with Clean's underlying semantics, if 
the great language genealogical diagram is correct...
see http://people.mandrakesoft.com/~prigaux/language-study/diagram.png)

> The only thing that the compiler needs to guarantee is that f a b
> always delivers the same exceptional value when applied to the same
> arguments. So, the expression (a + b) must always be evaluated in the
> same way within a single program. As far as I know this is normally
> so in non-concurrent evaluation schemes for "synchronous" exceptions.

Is the order of evaluation guaranteed in Clean?  In many languages it is 
implementation-specific (various Scheme systems will evaluate in different 
orders.)  Of course, your point is that they just must be consistent within a 
single program which is far more likely.

-Brent