SICP: The non-strict or lazy `cons`, how does it work?

Question

The following is an excerpt from the SICP book, Section 4.2.3 Streams as Lazy Lists:

With lazy evaluation, streams and lists can be identical, so there is no need for special forms or for separate list and stream operations. All we need to do is to arrange matters so that cons is non-strict. One way to accomplish this is to extend the lazy evaluator to allow for non-strict primitives, and to implement cons as one of these. An easier way is to recall (section 2.1.3) that there is no fundamental need to implement cons as a primitive at all. Instead, we can represent pairs as procedures:
(define (cons x y)
    (lambda (m) (m x y)))
(define (car z)
    (z (lambda (p q) p)))
(define (cdr z)
    (z (lambda (p q) q)))

Question: I don't see how the above definition of cons achieves lazy or non-strict behavior. For example, the following call to cons,

(define (foo) '(1 2 3))
(define bar (cons 'a (foo)))

does result in the invocation of foo at the point cons is called, which is a non-lazy or strict behavior.

So, how would we write a lazy or non-strict version of cons that is also not a special form.

The section presupposes that the code is evaluated by the lazy evaluator of the previous section, 4.2.2. — molbdnilo
Hmm. I somewhat suspected what you're saying here to be the case, but was not fully sure. E.g., the above section 4.2.3 motivates the problem faced in the earlier section 3.5.1 where special forms delay and cons-stream - the authors say - had to be necessarily used. This made it sound as if the authors are trying to get rid of special forms OUTSIDE of the evaluator in the current section 4.2.3. — Harry
@molbdnilo If you can repost your comment as a reply, I'll make it final. — Harry

Unknown Unknown · Accepted Answer · 2019-04-25T09:28:13

The section presupposes that the code is evaluated by the lazy evaluator of the previous section, 4.2.2. – molbdnilo, on Mar 2 '17 at 7:49.

SICP: The non-strict or lazy `cons`, how does it work?

1 Answers