# Comp202: Principles of Object-Oriented Programming II Fall 2006 -- Lecture #4: Design 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."
• 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.
• See the presentation in HTML format (the sub presentations and links to animations will not work however):

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

Last Revised Thursday, 03-Jun-2010 09:52:24 CDT

©2006 Stephen Wong and Dung Nguyen