[clean-list] Clean in the Real World

[Marco Kesseler]

>On Saturday 13 December 2003 3:02 pm, Marco Kesseler wrote:
>> 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)

Nice diagram, although I think that modern Clean has more in common 
with Haskell than the diagram suggests

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

Well, no. Strictness analysis may change the evaluation order (and 
concurrency too).

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

As far as I know, within a single program it will be fixed for 
"sequential" implementations. 

In fact, the imprecise exception paper also mentions that successive 
runs of the same pogram will in practice return the same exceptions, 
and that recompiling with different optimisation settings may lead to 
a different exception being thrown.

They also compare their solution to ML and "speculate" that having to 
do exception handling in the IO Monad is not awkward in practice. 
Well, I seriously doubt that. I think that being able to encapsulate 
exception handling completely within any function - like ML allows - 
is _essential_.

I do have to admit however that the solution that I proposed cannot 
deal with asynchronous exceptions, such as a user pressing "ctrl C" . 
These however, belong to the IO arena anyway I think. So that does 
not really worry me.

There are a few things that I am not yet sure of:
* Should all expression in principle be able to throw an exception? 
If this is not the case, we should use the type system to tell us 
which expressions may throw exceptions and which won't (which is 
nice!). This however can have big consequences if you change an 
expression so that it starts throwing exceptions. You may have to 
change a lot of types then, similar to the effects that adding 
uniqueness, or Monads may have.
* Is stack trimming really the right way to implement exception 
propagation? Suppose that an expression is evalutated as part of a 
pattern match, and it throws an exception. Should the exception then 
be caught (stack trimming), or should matching fail, and the next 
alternative tried? (this may have some intricate semantical 
consequences).
 
Marco