[clean-list] Clean in the Real World

[fzuurbie@inter.nl.net]

This is a multi-part message in MIME format.

--_----------=_107095662132661
Content-Disposition: inline
Content-Length: 1687
Content-Transfer-Encoding: binary
Content-Type: text/plain

> > 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.  However, from a pragmatic standpoint I wonder if their lack
> may make writing robust software in Clean more difficult.
> 
> Does Clean provide something like the exception model proposed in Simon
> Peyton-Jones et. al "A Semantics for Imprecise Exceptions"
> (http://research.microsoft.com/Users/simonpj/Papers/imprecise-exn.htm)?
> 
> What is the recommended approach for dealing with exceptional/error
> conditions in Clean?

Functional language have a history of pushing error situations from run time to compile time. Compile time type checking is one area. Deterministic parallellism is another. Both incur limitations on the programmer, compared with run time typing and non-deterministic parallellism. But they kill vast numbers of errors.

In Clean the Sparkle proof tool has emerged: why do you need exception handling if you can prove at compile time that exceptions will never occur? And of course, this will change (limit) the way we program or we will simply be unable to prove the absence of exceptions.

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.

Regards Erik Zuurbier 
--_----------=_107095662132661--