# COMP 202: Principles of Object-Oriented Programming II

Patterns for Lazy Evaluation

Consider the following lists:

• (0, 1, 2, 3, 4, 5, ...)
• (7, 14, 21, 28, 35, 42, ...)
• (A, B, C, A, B, C, A, B, C, A, B, C, ...)
• (0, 1, 1, 2, 3, 5, 8, 13, ...)
• (a, b, ab, bab, abbab, bababbab, abbabbababbab, ...)
• (1, 2, 3, 5, 7, 11, 13, 17, 19, ...)

Question 1: What do all these lists have in common?

• A list of all keyboard input from a user.
• A list of all customer transactions from a large company.
• A list of a the citizens of the world.

Question 2: How are these lists similar to the first set of lists above?

So how can we represent such large, or possibly infinite, lists in our system?

Let us refer to our normal, fully instantiated lists as "eager" lists.

Consider first the following design constraints:

• Since they are all lists, then they should behave the same as any other (eager) list in the system:
• They are either
• Empty, or
• Non-empty, where they have a first and a rest.
• All operations on regular, small finite lists should available on these new large lists.
• They should be able to accept and run all existing applicable algorithms on finite lists without modification
(Note that some algorithms may run in infinite time, e.g. length of the list-but it should still run without a computational error, except for running out of program memory.)
• If an element of a list has been accessed, then its behavior of the list up to that element should be identical in all ways to that of an eager list.

Consider this idea:

If an element of a list has not yet been accessed by any other object, can the rest of the system tell whether or not it even exists?

That is, if an object (the above mentioned list element) is not accessed by any other object, why bother instantiating it in the first place?   That is, if no one is referencing an object, it does not need to be instantiated.   This is very similar to the way in which the garbage collector works, except that the garbage collector un-instantiates an object after it has been used, and here we are talking about delaying an instantiation before an object is used.

### Laziness

The concept of delaying the instantiation of an object until just before it is used is called "lazy" instantiation.   In general, the concept of delaying a computation until just before its result is needed is called "lazy evaluation".    This is contrasted to the "eager" systems where the data is instantiated or computations are performed as soon as it is determined that such data or results might be needed later.

So, what we want to do is to design and build a lazy evaluated list where elements are instantiated only just before they are to be accessed for the first time.

The following is an updated presentation of our SIGCSE 2000 paper on "Design Patterns for Lazy Evaluation":

• Download the PowerPoint presentation and source code here: lazyeval.zip  (Warning!  4.4 MB file!)
• Macromedia projector problems?
• Error message:  "Director Player 6.0 - This program needs 3MB of free virtual memory to run."
• The animations were written quite some time ago and the version of Macromedia Director used cannot properly recognize the large virtual memory available on modern Windows XP systems.
• The solution is to temporarily set the computer's virtual memory to less than 500 MB.
• See the following links for more detailed information on how to accomplish this:
• Note:  If you get the error message: "Invalid projector file"
• The pathname might be too long.
• Move the projector files (be sure to move all of them) to a directory with a shorter total pathname, such as a temporary directory directly off the root of a drive.

Please see our original SIGCSE 2000 paper on Design Patterns for Lazy Evaluation.

Patterns for Lazy Evaluation

URL: http://www.cs.rice.edu/teaching/202/08-fall/lectures/lazy/index.shtml