In our lazy interpreter, we identified three points in the
language where we need to force evaluation of expression closures (by
invoking strict): the function position of an
application, the test expression of a conditional, and arithmetic
primitives. Doug Dolittle, a fairly sedentary student, is rather taken
with the idea of laziness. He suggests that we can reduce the amount
of code we need to write by replacing all invocations of strict with
just one. In the lazy interpreter from class (PLAI chapter 8), he
removes all instances of strict and replaces
[id (v) (lookup v env)]with
[id (v) (strict (lookup v env))]
Doug’s reasoning is that the only time the interpreter returns an expression closure is on looking up an identifier in the environment. If we force its evaluation right away, we can be sure no other part of the interpreter will get an expression closure, so removing those other invocations of strict will do no harm. Being lazy himself, however, Doug fails to reason in the other direction, namely whether this will result in an overly eager interpreter.
Is it possible to write a program that will produce different results under the original
interpreter and Doug’s? Let the interpreted language feature arithmetic,
first-class functions, with, if0, and rec
(even though these are not in our in-class lazy interpreter).
If so, hand in an example program and the result under each interpreter, and clearly identify which interpreter will produce each result. Be sure to compare this behavior against that of the lazy interpreter of the sort we’ve written in class rather than the behavior of Haskell! Note: it should not be difficult to construct test interpreters from your solution to the Extended Interpreter assignment and the code we give you in the textbook. You may use these to help you test your conjectures.
If it's not possible, defend why one cannot exist, and then
consider the same language with cons, first,
and rest added. Also, keep in mind that the REPL is
always a strictness point. If you were running your lazy interpreter
from DrScheme, you would type the following into the interactions
window:
> (strict (interp '{...} (mtSub)))
...
You do not need to turn in any interpreters for this problem --
just submit the example program, what answer it _would_ produce
under each of the two interpreters, and any other explanation
requested in the problem.
No lazy language in history has also had state operations (such as mutating the values in boxes, or assigning values to variables). Why not?
The best answer to this question would include two things: a short program (which we assume will evaluate in a lazy regime) that uses state, and a brief explanation of what problem the execution of this program illustrates. Please be sure to use the non-caching (ie, original) notion of laziness. If you present a sufficiently illustrative example (which needn’t be very long!), your explanation can be quite short.