[clean-list] Clean in the Real World

[Marco Kesseler]

It's hard to keep up with you Fergus! I still have to write an answer 
to your original response...

Fergus wrote
>On 15-Dec-2003, Marco Kesseler <m.wittebrood@mailbox.kun.nl> wrote:
>> >On 15-Dec-2003, Arjen van Weelden <arjenw@cs.kun.nl> wrote:
>> >> As I see it, catching exceptions is only non-deterministic between 
>> >> compilations.
>> >
>> >You may see it that way, and it might perhaps even be true for the
>> >current Clean implementation, but that's not the case in general.
>> >IMHO imposing that as a requirement would unduly restrict the
>> >compiler's freedom to optimize code.
>> 
>> As long as it optimises at compile time, it is free to do whatever it 
>> wants, except at a few locations that hold catch statements.
>
>That's not correct.  If you want to preserve the nice properties of
>pure functional programming, then optimization would be inhibited in any
>code which might be called from a catch statement.

a) I don't see why (see below).
b) usually, one does not call a lot of code in exception handlers.

>Since it is common
>practice to put an exception handler at the very top level, this would
>typically mean the entire program.

a) I have to disagree. It would not be uncommon to have exception 
handlers deeper down, provided that the language does not make it 
almost impossible.
b) Most code does NOT get called by the handler. Or are you referring 
to the guarded code?

>If you don't inhibit such optimizations, then you would end up in the
>situation where applying simple and obvious transformations such as
>replacing a variable with its definition might change the program's
>behaviour.

Suppose I have:

Start
    = program
    catch DivideByZero = abort "divide by zero"
    catch StackOverFlow = abort "stack overflow"
    catch ...

Yes, I agree that it depends on the optimisations which exception 
will get thrown first. But I don't see why the "program" expression 
cannot be optimised. All functions without catch statements can be 
optimised as usual. Optimisations just cannot obviously go "through" 
(a few) functions with a handler.

>> And then, there is still the possibility to enforce catch statements 
>> to always deliver the same constant expression on any exception.
>
>Not if you permit statements that might not halt.  Otherwise the compiler
>in general still can't reorder code, such as the evaluation of x and y in
>"x + y", because "catch(1/0 + loop)" will terminate whereas
>"catch(loop + 1/0)" will loop.
>
>Automatic termination analysis is still not yet good enough to want to
>rely on it -- after all, this is the classic halting problem!

Well, perhaps we are not thinking/talking about the same thing. I 
meant to say that the _handler_ always delivers the same expression 
for the same set of function arguments, independed of the actual 
exception it caught (i.e. independent of optimisation). In that way, 
it becomes impossible to detect from the outside of the function 
(Start above) what exception was throw. This is trivially so, if the 
handler does not get the exception value as an argument.

It would be sad however, to loose the exception information, so I 
consider this to be a last resort.

>-- 
>Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
>The University of Melbourne         |  of excellence is a lethal habit"
>WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.