7.2.1 Directly Useful for the Assignment🔗

To understand laziness from a desugaring perspective, read the DCIC section about streams, which also shows how they can be encoded in an eager language.

Furthermore, to understand laziness from an interpreter perspective, see the Laziness chapter in PLAI 3/e.

7.2.2 Optional Reading🔗

To see more examples and understand the beautiful programming patterns that laziness enables, read this classic paper by John Hughes (not Brown’s Spike), entitled Why Functional Programming Matters.

7.3.1 Language Extensions🔗

7.3.2 Lazy Evaluation🔗

Lazy evaluation means that arguments to functions should not be evaluated if they are not used in the body. As a result, function calls and the pair constructor must be lazy: that is, a function must not evaluate its argument if it is not used, and a pair must not evaluate its parts if they are not used. The right-hand side of a let should also be lazy. It is good to have tests that ensure all these are indeed lazy.

To implement this, create a new kind of value, called a computation. A computation contains not a value but an expression, and perhaps other parts needed for this to make sense. At various points, defined below, a computation must become a value, but the essence of laziness is that it does not have to happen before then (and hence maybe never at all).

7.3.3 Strictness Points🔗

Certain parts of the language must, if given a computation, force it to turn into a value. These are called strictness points. We define the following to be strictness points of Lazy Paret:

• The arguments to operators +, ++, first, second, num=, str=, and is-pair.

• The conditional expression in an if.

• The function position of an application.

• The final, top-level result if any (so that the user sees an answer).

• Anywhere in the source program that invokes the strict operator.

You will find it useful to define a function, force, that converts computations into values by (effectively) evaluating the expression contained in the computation.