[clean-list] Clean in the Real World

[Marco Kesseler]

>On Mon, Dec 08, 2003 at 03:19:30PM -0800, Brent Fulgham wrote:
>> > Clean lacks exception handling though. If (a part of) an 
>> > application runs out of stack or heap space, the application 
>> > just quits.
>> 
>> This makes some sense, since Exceptions (by their nature) are not 
>>functional.
>
>Well, that's arguable. You can in principle do exceptions as values, 
>e.g. have everything
>return a type which contains a value and a flag to indicate whether 
>the value is to be
>treated as an exception.

Exactly.

>But that changes the semantics of your program (and how you write it).

In theory yes, but not in practice. At the moment, if something goes 
wrong, you _have_ to pass up the error information explicitly. And 
this _really_ changes the way you have to write your program. If a 
language supports exceptions, a lot of this error propagation would 
happen implicitly, and I suspect that you end up with a cleaner program.

>It's not that it can't be done in a functional way, it's that
>it's a highly questionable way to do it - for performance and 
>genericity reasons,
>for example. In terms of performance, you'd have all these checks 
>going on all the time
>every time you compute anything at all.

If the language and its runtime system supports it, it remains to be 
seen whether it would (seriously) hurt performance. If some "strict" 
evaluation takes place on the stack, the compiler might do the same 
tricks that currently take place in imperative languages. And while 
matching nodes, the compiler could easily add a check for an 
exception value at the end of the match sequence where it now 
complains about non-matching rules. That would not hurt performance a 
bit.

>In terms of genericity, you could either make only some functions 
>support exceptions
>(which would limit their reusability) or make all functions support 
>exceptions - which
>would motivate moving exception machinery into the language itself, 
>rather than
>redundantly putting it everywhere. And then are you going to lose a 
>little bit of
>purity? Well, yes - but in translating a program into 
>exceptions-as-value style you
>in general lose a little bit of purity anyway, namely opacity of 
>order of evaluation.

As long as no exceptions occur, your program will be purer than 
having to explicitly check for errors all the time. And if they do, 
well who cares about purity then? Everything is better than just 
bailing out. And strictly speaking, exceptions-as-values are not 
impure at all. If you want to, you can already put all data in a 
"Maybe" type. It is just a lot of coding.

>Given that in the real world, "exceptional" conditions such as 
>network I/O problems
>cannot be "proved away" (unlike how in principle you could prove a 
>bound on memory
>usage of a program), clearly some notion of exceptions is essential 
>for some applications.
>It follows, IMO, that all functions should be able to propagate 
>exceptions - because
>any function might in principle be passed a value that cannot be 
>evaluated because
>an exception has occured.

Yes.

Erik Zuurbier wrote:
>When I look around me where I work, software is littered with 
>throwing and catching
>exceptions. I sometimes wonder whether the programs do anything else 
>at all. The
>ease with which a programming problem is delegated to an ill 
>understood run time
>mechanism (exceptions handling that is) sometimes scares me. One 
>should not be
>allowed to call such programs programs ('written beforehand') at all.

Exceptions are for the things you _cannot_ catch compile-time. No 
proof system will ever
be able to get rid of those. And if you want to write more than a toy 
program, you _have_
to deal with them.

regards,
Marco