[clean-list] Clean in the Real World

Robin Green greenrd@greenrd.org
Tue, 9 Dec 2003 01:34:19 +0000


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. But that changes the semantics of your program
(and how you write it). 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.

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.

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.

-- 
Robin