Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!munnari.oz.au!bruce!mmcg
From: mmcg@bruce.cs.monash.OZ.AU (Mike McGaughey)
Newsgroups: comp.lang.functional
Subject: Re: Can laziness sometimes be too lazy?
Message-ID: <2734@bruce.cs.monash.OZ.AU>
Date: 24 Jul 90 17:25:36 GMT
References: <3188@osc.COM>
Organization: Monash Uni. Computer Science, Australia
Lines: 92


This is something I said recently by mail (edited); I hope it
clarifies my interest somewhat:

-----
> It is simply
> a matter of which properties you prefer to have satisfied:

Yes, indeed.  There is, however, a basic inconsistency which arises
when using lazy languages - the routine that prints the result of the
expression has to be strict.

Now, this means that if I had just written:

    (first 2 [])

the program would have failed; if I then incorporate that program into
a larger program that takes the length, naively, I would expect that to
fail too.  It's perfectly obvious that it won't, of course, but you get
the idea - one would like to be able to simply glue functions together
and have the system do just what it would have done on the functions
individually.

So, laziness affects one of the basic strengths of functional
programming - the composition of functions doesn't always preserve the
semantics of those functions.  More precisely, it *does* preserve the
semantics of individual functions, but the failure semantics of a
function may not be propogated upwards when you naively expect it to
be.  It seems that the programmer has to be aware of subtleties he
shouldn't really need to worry about - he sometimes needs to know
whether the value being computed will actually be inspected or not!

I am actually a part of the 'lazy lobby', so I am happy to live with
this "problem".  However, it's an interesting anomaly, considering
the aforementioned functional philosophy.
-----

On reflection, there are a number of possible responses to my query -
the most common one has been "your program is incorrect - rewrite it".
This is manifestly obvious and misses the point.  It might be closer to
the mark to say that the example illustrates that lazy programmers are
safer programming in a top down fashion, or in such a way that they
never rely on a function's failure, or always making their intentions
clear by using pattern matching (but there are certainly cases where
pattern matching won't help.  And what about languages that don't have
pattern matching?  Also, could automatic program transformations cause
problems here?).

There seems to be a fundamental inelegance in having to know whether or
not the result of a function will actually be inspected by a program.
It's not very modular.  Is this important, from either a semantic or
reliability point of view?  Is it a symptom of something much deeper?
Is there an elegant fix for lazy languages which preserves laziness, in
all its glory, as well as allowing cleaner functional glue?  Is it
fundamentally impossible? (I suspect so, but perhaps there is a radical
solution).

This is not just a case of "Well, don't write programs that fail".  We
are, in a deeper sense, talking about whether it is possible to cleanly
integrate exception handling into a lazy language.  Those of you who
have used (say) SML will realise just how useful this could be.

One more thing:

jgk@osc.COM (Joe Keane) [23 Jul 90 22:48:39 GMT]:
> 
> One thing that you are allowed to do is change bottom into
> some valid value, as long as you're consistent.  I won't explain this, except
> to point out that a program which gets stuck can't contradict one that does
> something useful. [etc]

Program SomethingUseful :-)

let IncomingMissiles = (first 20 Missiles)
in
    if (length IncomingMissiles) > 0 then
	CounterAttackLaunchCode
    else
	PeacefulCode


For something more prosaic along the same lines, try an operating system.

So, if you have any ideas...

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

"His state is kingly; thousands at his bidding speed,
 And post o'er land and ocean without rest."
	- Milton.