🚀 go-pugleaf

In article <4043@osc.COM>, jgk@osc.COM (Joe Keane) writes:
>In article <1990Nov24.121432.29282@newcastle.ac.uk>
>D.A.Harrison@newcastle.ac.uk (Dave Harrison) writes:

DH: I have doubts that an alternative approach would do any better, though
DH: obviously I can't prove it. My belief is that it is more or less impossible
DH: to produce an exception mechanism that significantly enhances the
expressive
DH: power of a language without losing "normal" lazy evaluation semantics.

JK: Yikes, i have to disagree with that last statement.  I'd be interested in
JK: seeing a quick description of the major problems between exception handling
JK: and lazy evaluation.

JK: There is a question of whether functions should be `strict in exceptions'.
JK: Clearly if a function is strict in the value of some argument,it
should also
JK: be strict in an exception in that argument.  Otherwise, it could go either
JK: way.  I'm convinced that you want both possibilities at different
times, and
JK: therefore a good functional language should support both.

DH :

Consider the following (psuedo-Miranda) function :

	inclist :: [ num ] -> [ num ]

	inclist []
	  = []

	inclist (x : xs)
	  = x + 1 : inclist xs,			if x >= 0
	  = (signal Bad_num x) : inclist xs,	otherwise

This works on lazy lists; only the head of the argument list needs be forced to
increment the next element.

Consider the expression :

	hd (inclist [100,99,-1])

The result of this expression is

	101

If the inclist function is strict in exceptions then it must evaluate the whole
of its argument to determine that its last element will indeed cause an
exception to be raised. 

	=> inclist is strict in its argument

The raising of an exception is a possible consequence of the evaluation of an
expression. Thus, if the evaluation of an argument may raise an exception then
a function which is strict in exception must evaluate that argument to
catch any exceptions

	=> A function which is strict in exceptions will be strict in any
	   arguments which may raise exceptions.

The reverse is also true : If a function is lazy in some of its arguments then
it will be lazy on any exceptions that those arguments raise.

As usual the strict case is easy to handle : just evaluate everything. To
handle the lazy case you have to ensure that exceptions do not propagate "out
of" lazy operations.

For example in the inclist function the exception (signal Bad_num x) must be
handled and a recovery value substituted for the signal at that point; then the
(lazy) cons can take place. If there is no exception handler for the Bad_num
exception at that point then tough : the program crashes. To allow the
exception to propagate "out of" the cons would make cons a strict operator.

Unsatisfactory, but at least it preserves lazy semantics. I can't think of a
better solution but if anyone else can I'd love to see it (how about a joint
paper, I could use the publications :-)).

Dave

---------------------------------

Dave Harrison				JANET: D.A.Harrison@uk.ac.newcastle
Computing Laboratory			PHONE: +44 91 222 7784
University of Newcastle upon Tyne
Newcastle upon Tyne NE1 7RU
U.K.

"Some of your men have taken seeds of truth, 
 And planted fields of hate" 			- RunRig "Eirinn"
"Failte gu Tir an Airm"				- RunRig "Tir an Airm"