[clean-list] Clean in the Real World

[Marco Kesseler]

Arjen van Weelden wrote:
>Brent Fulgham wrote:
>> Does Clean provide something like the exception model proposed in 
>>Simon Peyton-Jones et. al "A Semantics for Imprecise Exceptions" 
>>(http://research.microsoft.com/Users/simonpj/Papers/imprecise-exn.htm)?
>
>Clean 2.1 for Windows comes with a small library (Libraries\
>ExceptionsWindows\StdException) that implements user-defined
>(synchronous) imprecise exceptions using machine dependent ABC-code and
>Dynamics. At least, it ought to implement just that, but it needs more
>users to really test it. It should problably be rewritten in assembly,
>incorporated into Clean's run-time system, and ported to the other
>platforms.

Having read a part of the paper of Simon Peyton Jones et al. about 
imprecise exceptions, I must say that this is not exactly what I had 
in mind myself.

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.

The writers end up putting getExeption in the IO Monad, and then 
suddenly it _is_ allowed to non-deterministically choose one 
exception value, supposedly without hurting referential transparancy. 
If all the interesting stuff must end up in the IO Monad I'd rather 
just use a real imperative language (sorry if I hurt anybodies 
feelings, but some Monad tricks are getting on my nerves).

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.

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.

regards,
Marco