🚀 go-pugleaf

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 =
		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.

If we replace those IFs with pattern matching, which is slightly
stricter than it needs to be, we get a pattern match failure.

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.

Is this problem well known?  Has anyone any insight into what the
language "should" do, and why?  Is it just a case of the increased
freedom of laziness introducing a more subtle class of errors?

Mike.
--
Mike McGaughey			ACSNET:	mmcg@bruce.cs.monash.oz