🚀 go-pugleaf

Mike McGaughey)
>>>	Are there situations where lazy evaluation is *too* lazy?
>>>	The following example (due to Lloyd Alison) shows what I mean:
>>>	Let
>>>		rec first n l be
>>>			if n = 0 then [] else (hd l).(first (n-1) (tl l))
>>>	and
>>>		rec length l be
>>>			if l = [] then 0 else 1 + length (tl l)
>>>	in	length (first 2 [])
>>>
>>>	In a strict language, the result is an error,
>>>	due to the (tl []) in "first".
>>>	In a lazy language (LML here), you get the result 2.
>>>
>>>	The problem, in this case, is that "length"
>>>	is passed a list of closures (of length 2)
>>>	which are never evaluated, but which correspond
>>>	to nonexistent list elements.
>>>	 What "should" the language do, and why?

Tom Blenko:
>>	I don't think there's a good answer to your question
>>	(as it relates to this example, anyway) unless it is clear
>>	what 'first' is intended to mean.
>>	What is supposed to be the result of `(first 2 [])', for example?

In a lazy language, you have two choices.
You can define the result to be "bottom",
(the least-defined domain element, according to the partial-order).
This approach emphasizes flexibility at the expense of safety,
and is therefore appropriate in a language for building prototypes.
Or, you can use strong typing to catch all such operations
at compile-time and reject such programs as illegal.  
This approach emphasizes safety at the expense of flexibility,
and is therefore more appropriate for building a production system.

Wolfgang Grieskamp:
>	The intended definition is obviously: ...

If the language was defined via an operational semantics,
then whatever result the standard implementation provides
is the correct result, by definition.  However,
here there seem to be doubt as to whether
the result is really what the implementor intended.

Such questions are less likely to arise when
the language is defined via denotational semantics.
Rather than defining the constructs implicitly
via a black-box implementation, denotational semantics
gives the intended meaning more directly.
This is surely one of the motivations its development.

Wolfgang Grieskamp:
>	According to my experience pure "lazyness" seems 
>	not be the way to solve the "software-crisis".
>	I believe strictness makes programs easier to understand,
>	to valificate, to verify, and (consequently) to manipulate formally.
>	There is only a small number of problems which are naturally
>	normal-order (streams). 

One of my research projects is a language offering
_both_ lazy and strict constructs, so the programmer
can consider the situation and choose appropriately.

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