🚀 go-pugleaf

blenko-tom@CS.YALE.EDU (Tom Blenko) writes:

>In article <2706@bruce.cs.monash.OZ.AU> mmcg@bruce.cs.monash.OZ.AU (Mike McGaughey) writes:
>|
>|let rec first n l =
>|		if n = 0 then []
>|		else (hd l).(first (n-1) (tl l))
>|and rec length l =
>|		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.
>| [..]

>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.  The given definition for 'first' appears to be incorrect.

>What is supposed to be the result of

>	(first 2 [])

>for example? A "correct" version of 'first' might be

>	let rec cfirst n l =
>			if n = 0 then []
>			else if l = [] then []
>			else (hd l).(cfirst (n-1) (tl l))

>in which case the indicated behavior does not occur.


The intended definition is obviously:

	let rec first n l =
			if n = 0 then []
			else if l = [] then BOTTOM 
			else (hd l).(cfirst (n-1) (tl l))

where BOTTOM must be an unslightly polymorphic zero-arity function!! 
The example enlightens the pain of "lazy" languages (beside the
notion, which stands only for some implementation detail, but not
for a sematical concept). 

(-:

You folks of the lazy lobby (so silent about Mikes 
example?), have you ever written larger programs in NOR languages?
Of course you have, but no debugging was necessary, because
they have been totally correct from the beginning. 

Say, have you ever delegated a programming task in a NOR language
to someone else, for example, to a student, and then must use yourself
this service? Of course you have, but your students (or assistants,
to step upwards) always write totally correct programs, and so there
was no need to view hours all of your excellent code and figure out
at least a bug in a trivial function at a totally other place.

:-)

Very seriously, according to my experience pure "lazyness" seems 
not be the way to solve the "software-crisis". Some might imagine
marvelous debuggers buts thats an old argument of the von-Neumann 
fraction. 

I believe strictness introduces a kind of redundancy, which 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). 
The rest is only some kind of dirty programmer optimization 
(if I reduce "lazy" bool conjunction over a list, then it stops when 
the first FALSE occurs and something like this).

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Wolfgang Grieskamp 
wg@opal.cs.tu-berlin.de tub!tubopal!wg wg%opal@DB0TUI11.BITNET