🚀 go-pugleaf

In article <1990Nov24.121432.29282@newcastle.ac.uk> D.A.Harrison@newcastle.ac.uk (Dave Harrison) writes:
>    ...more complicated is to handle the propagation of exceptions
>	in a lazy functional language.
>	I was one of the authors of a couple of papers on exception 
>	handling in lazy functional languages. 
>	Our major interest was to handle (the propagation of) exceptions
>	in a way that preserved lazy semantics and commutativity of operators.
>    ...
>	Although we mangaged to achieve the aim of preserving
>	lazy semantics and commutativity, we had to restrict
>	the power of the exception signalling, propagation
>	and handling mechanism so much that what we ended up with
>	could be expressed relatively straight forwardly
>	in a lazy functional language such as Miranda.
>
>	I have doubts that an alternative approach would do any better,
>	though obviously I can't prove it. My belief is that it is
>	more or less impossible to produce an exception mechanism
>	that significantly enhances the expressive power of a language
>	without losing "normal" lazy evaluation semantics.

I agree.  If exception-handling is powerful, then there
is no longer anything "exceptional" about exceptions
-- they merely become new data objects to be added to the domain
(objects whose presence tends to sequentialize operators
which would otherwise be commutative).

If you don't care about handling exceptions,
but want only to report them to the user,
then one might move these messages to the meta-level
--- viewing them as the comments of a default runtime-debugger.
The base language itself can then ignore the distinctions
in the kinds and causes of errors, and treat "error"
analogously to the way it treats "bottom" (i.e. undefined).
In fact, if one omits exception-handling completely,
it becomes reasonable to map exceptions to "undefined" (bottom)
in the semantics, and leave more detailed explanations
to the language environment.

	Frank Silbermann	fs@cs.tulane.edu
	Tulane University	New Orleans, Louisianna  USA