🚀 go-pugleaf

From article <3109@caesar.cs.montana.edu>, by icsu8209@caesar.cs.montana.edu (Lou Glassy):
> What does 'lazy evaluation' mean?  Is it the same thing as 'short-circuit evaluation?
> 

Not the same, but quite similar. The term 'lazy evaluation' is borrowed from
the lambda calculus. Very loosely it means that evaluations of all expressions
other than the final one are defered until such time as the values are needed
in another calculation. If it turns out that the value of a subexpression
is never needed, ( e.g. because it is the unselected alternative of an
if-else-expression),  it is never calculated.

This has a couple of effects. One is that you get more expressions to
evaluate to something, rather than going into infinite evaluation loops, or
'crashing' from divide-by-zero or whatever. In fact, you get exactly the
theoretically largest algebra possible, the one the theorists seem to
use exclusively.

Another effect is that you can write programs in such a way that the
progress of the evaluation of two separate expressions can be controlled
by the evaluation of a third.  In this way one can control the realtime
sequencing of the evaluations. Evaluation of the first expression causes
the subexpressions of the other two to be done in a particular order by
'needing' them in that order. In the parlance of sequential programming
languages, you then have three 'processes': one 'monitor', and two
'child-processes'. Of course, this can be extended to any number of
processes and any kind of connectivity.

At least some lazy evaluation is necessary in any system. Only the most
trivial programs would ever terminate otherwise. (As noted, the unselected
alternative of an if-else-expression is seldom calculated.)
Systems which use lazy evaluation exclusively are rare. In LISP, it's
mainly the evaluation of the CONS record that makes the next
big difference. If that evaluation is defered, you can use lists as
event-queues.