[clean-list] Clean in the Real World

Fergus Henderson fjh@cs.mu.oz.au
Tue, 16 Dec 2003 01:37:52 +1100


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.  Since it is common
practice to put an exception handler at the very top level, this would
typically mean the entire program.

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.

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

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