In section 1.1, where we began our discussion of models of evaluation, we noted that Scheme JavaScript is an applicative-order language, namely, that all the arguments to Scheme JavaScript procedures functions are evaluated when the procedure function is applied. In contrast, normal-order languages delay evaluation of procedure function arguments until the actual argument values are needed. Delaying evaluation of procedure function arguments until the last possible moment (e.g., until they are required by a primitive operation) is called lazy evaluation.[1] Consider the procedure function

Original	JavaScript
(define (try a b) (if (= a 0) 1 b))	function try_me(a, b) { return a === 0 ? 1 : b; }

Evaluating (try 0 (/ 1 0)) generates try_me(0, head(null)); signals an error in Scheme. JavaScript. With lazy evaluation, there would be no error. Evaluating the expression statement would return 1, because the argument (/ 1 0) head(null) would never be evaluated.

An example that exploits lazy evaluation is the definition declaration of a procedure function unless

Original	JavaScript
(define (unless condition usual-value exceptional-value) (if condition exceptional-value usual-value))	function unless(condition, usual_value, exceptional_value) { return condition ? exceptional_value : usual_value; }

that can be used in expressions statements such as

Original	JavaScript
(unless (= b 0) (/ a b) (begin (display "exception: returning 0") 0))	unless(is_null(xs), head(xs), display("error: xs should not be null"));

This won't work in an applicative-order language because both the usual value and the exceptional value will be evaluated before unless is called (compare exercise 1.6). An advantage of lazy evaluation is that some procedures, functions, such as unless, can do useful computation even if evaluation of some of their arguments would produce errors or would not terminate.

If the body of a procedure function is entered before an argument has been evaluated we say that the procedure function is non-strict in that argument. If the argument is evaluated before the body of the procedure function is entered we say that the procedure function is strict in that argument.[2] In a purely applicative-order language, all procedures functions are strict in each argument. In a purely normal-order language, all compound procedures functions are non-strict in each argument, and primitive procedures functions may be either strict or non-strict. There are also languages (see exercise 4.40) that give programmers detailed control over the strictness of the procedures functions they define.

A striking example of a procedure function that can usefully be made non-strict is cons pair (or, in general, almost any constructor for data structures). One can do useful computation, combining elements to form data structures and operating on the resulting data structures, even if the values of the elements are not known. It makes perfect sense, for instance, to compute the length of a list without knowing the values of the individual elements in the list. We will exploit this idea in section 4.2.3 to implement the streams of chapter 3 as lists formed of non-strict cons pairs. pairs.

Exercise 4.34 Suppose that (in ordinary applicative-order Scheme) we define Suppose that (in ordinary applicative-order JavaScript) we define unless as shown above and then define factorial in terms of unless as

Original	JavaScript
(define (factorial n) (unless (= n 1) (* n (factorial (- n 1))) 1))	function factorial(n) { return unless(n === 1, n * factorial(n - 1), 1); }

What happens if we attempt to evaluate (factorial 5)? factorial(5)? Will our definitions functions work in a normal-order language?

Solution

(provided by GitHub user joeng03) When evaluated in default (‘strict’) mode, the code undergoes applicative order reduction and runs into an infinite loop because it needs to evaluate the arguments of the unless function, but the factorial function does not have a terminating condition. When evaluated in lazy mode, the code undergoes normal order reduction. It produces the correct output because the unless function is applied before its arguments are evaluated.

Exercise 4.35 Ben Bitdiddle and Alyssa P. Hacker disagree over the importance of lazy evaluation for implementing things such as unless. Ben points out that it's possible to implement unless in applicative order as a special syntactic form. Alyssa counters that, if one did that, unless would be merely syntax, not a procedure function that could be used in conjunction with higher-order procedures. functions. Fill in the details on both sides of the argument. Show how to implement unless as a derived expression (like cond or let), and give an example of a situation where it might be useful to have unless available as a procedure, rather than as a special form. Show how to implement unless as a derived component (like operator combination), by catching in evaluate applications whose function expression is the name unless. Give an example of a situation where it might be useful to have unless available as a function, rather than as a syntactic form.

Add solution

There is currently no solution available for this exercise. This textbook adaptation is a community effort. Do consider contributing by providing a solution for this exercise, using a Pull Request in Github.