University of Virginia, Department of Computer Science CS200: Computer Science, Spring 2002

 Problem Set 5: Non-Prosaic Mosaics

 Honor Code Reminder: If you are currently taking CS200, it is a violation of the course pledge to look at Problem Set answers and discussions from previous years. Please don't do it.

 Question 1: (2 points) a. Draw the global environment at the end of the interactions above, showing the values of MU, MU-lst and MUMU-lst. b. For the evaluation of MUMU-lst labeled g, DrScheme prints #0=((42 2 3) . #0#). Explain why it prints this instead of the normal way of printing the value of MUMU-lst and why the evaluation of (mlength MUMU-lst) does what it does.

a. This question was a mistake on my part — I should have asked you to draw some easy environment diagrams first before trying such a tricky one. No one really got this, so it seems like it would be a good idea to have an exam question about it. Drawing environment diagrams is pretty tedious, but its important that you are able to do this and really understand the environment model of evaluation. See SICP 3.2 for a full explanation.

You only had to show the environment at the end, but we'll show all the steps here.

> (define MU 42)

Creates a place named MU in the global frame, containing the value 42:

> (set! MU MU)
Recall the evaluation rules carefully --- set! evaluates its second sub-expression, and stores its value in the place named by the first sub-expression. So, we first evaluate MU. Its a name, we look up the value in the associated place and find 42. Then, we store that value in the place named MU. After this, the global environment is unchanged from before.
> (set! MU 27)
Puts the value 27 in the place named MU in the global frame:

> (set! MU (+ MU MU))
Puts the value 54 = (+ 27 27) in the place named MU in the global frame.
> (define MU-lst (list MU MU MU))
Creates a place named MU-lst in the global frame. Put the value we get from evaluating (list MU MU MU) in that place. That is the value of (list 54 54 54), since list is a normal procedure and its parameters are evaluated first. The resulting value is a cons pair of 54 and (list 54 54) (which is also broken down into cons pairs). This looks like:

> (set! MU 42)
Puts the value 42 in the place named MU. From the environment diagram above, it should be clear that this has not effect on MU-lst.
> (define MUMU-lst (list MU-lst MU-lst))
Creates a place named MUMU-lst in the global frame. Put the value we get from evaluating (list MU-lst MU-lst) in that place. Note that the list MU-lst evaluates to the cons place, not to the list. This looks like:

> (set! MU-lst (list 1 2 3))
Puts the value we get from evaluating (list 1 2 3) in the place named MU-lst. Note that the car and cadr of MUMU-lst still point to the old list:

> (define MUMU-lst (list MU-lst MU-lst))
I should have used (set! MUMU-lst (list MU-lst MU-lst)) instead of define here. A place called MUMU-lst is created (since we used define, a new place is created, but because it has the same name as the old place, we can no longer find the old MUMU-lst place, so we remove it from our envirnoment). Puts the value we get from evaluating (list MU-lst MU-lst) in that place:

Note the old list (54 54 54) is now garbage --- there is no expression we could evaluate to see the list. Garbage is actually a technical term for places that cannot be reached by evaluating any expression. Scheme implementations have a garbage collector that cleans up the garbage so we can reuse the space they are wasting with other places. (You don't need to know about garbage collection for this course, but see SICP p. 540 if you are curious to know how this works. But, if anyone asks you to take the garbage out, remember that its not garbage until it is already out, since it is still reachable! This is why most computer scientists have messy offices.)
> (set-car! MU-lst 42)
Puts the value 42 in the car part of the cons in the MU-lst place. This changes the value of MUMU-lst, since it points to that cons also:

> (set-cdr! MUMU-lst MUMU-lst)
This is a tricky one, but if we follow the evaulation rules carefully it should be clear what to do. To evaluate set-cdr! we put the value of the second subexpression in the cdr part of the cons cell the first subexpression evaluates to. So, the value of MUMU-lst is the cons cell the name MUMU-lst points to. We replace the cdr of that cons cell with that value (the new arrow is shown in bold):

We can remove the garbage to leave:

b. From the environment diagram, it is clear to see why (mlength MUMU-lst) doesn't terminate. The cdr of the cons named by MUMU-lst is the cons named by MUMU-lst. Hence, we can keep doing cdr forever, but never reach null. DrScheme is clever enough to not attempt to print this. Instead, it uses #0# to represent the cons cell named by MUMU-lst.

 Question 2: (8 points) Modify the mosaic code to create a program that makes a primosaic. Produce a good primosaic and put it in your public_html directory. For full credit, your program should be elegant and concise.

My primosaic code is here.