Eli Bendersky's website - SICP

Signed copy of SICP

2008-06-06T07:59:28-07:00

A lot of people were impressed by my finishing the read-through of SICP, completing the vast majority of the exercises. I received a lot of warm comments on my conclusion post - in the blog, on email, and on the Reddit link that immediately took place #1 in the Programming section and held it for a day.

The most interesting feedback was, however, from Geoffrey S. Knauth. He's acquainted with the book authors, and when he told them about my project, they agreed to sign a book for me, which Geoffrey then shipped to Israel on his own expense.

Here's the book and a slip of paper displaying the complex logistics behind this shipment:

And this is the opening page, with the authors' signatures:

I'm really happy about this, and want to thank Geoffrey again for his initiative.

Book review: "Structure and Interpretation of Computer Programs" by Harold Abelson, Gerald Jay Sussman

2008-05-28T07:38:56-07:00

I have the habit of writing reviews for the books I've read, and recently I noticed that something is missing. SICP. I've definitely read it, so I should probably write a review, eh ?

The real reason for my writing this review is, however, its Amazon entry. Although the first page shines with glimmering reviews by, no less, Peter Norvig and Paul Graham, the book has a 3.5 star average, which is really inexplicable. Many far inferior books have higher grades! So I want to make my small contribution by writing SICP the review it deserves, give it the grade it deserves (5!!!!), and post it to Amazon as well. Lets get started, then.

My first encounter with SICP was in the second year of university, where I took a course named "SICP 1". I already had working programming experience by that time, so the course wasn't hard, but I was struck by the beauty of the subjects it taught, by the Scheme language it used and by the long and interesting homework assignments it had. This course woke my curiosity about functional programming, and the Lisp family of languages in particular.

A few years later, with much more experience behind my back, I've decided to tackle SICP seriously and read the whole book, solving the vast majority of the exercises. This endeavor took about 10 months, and I enjoyed it immensely. I think SICP is a wonderful book, a seminal work in the field of programming. It is one of those rare books every programmer should read. In this review I'll try to explain why.

In contrast with most introductory books about programming that just teach you a language, SICP takes a far better approach. The main goal of the authors is not to teach Scheme, it is to teach programming. From the beginning, the book takes an integrative path, where the basic axioms of programming are presented, and later are fortified with examples and exercises. SICP teaches about computational processes - iterative and recursive. How to use them best in each situation, and how to implement them. It also explains abstraction by functional composition. These are topics rarely presented in programming books, but SICP puts them rightly in the first chapter, because they are the real stuff programming is based on.

The example programs developed in the book are real, large, and exciting. You'll get to develop a powerful picture language, a generic object-oriented arithmetic package including complex and polynomial arithmetic, a simulator for digital circuits, a symbolic differentiation package, an interpreter for Scheme written in Scheme, an interpreter for a logic programming language similar to Prolog, a virtual machine for a simplified pseudo-assembly DSL, an interpreter for Scheme written in this pseudo-assembly, and finally a compiler from Scheme to the assembly language. All these examples are real, well-thought out exercises for skill, taken from beginning to a very complete end. In no other book such a wealth of topics is addressed in an accessible manner.

A word about exercises in SICP. They are numerous, some of them are hard, but the exercises are the best way to really understand what the book tries to teach. In a manner, they're as integral part of the book as the text itself. The exercises are very well prepared and lead the reader through the examples coded by the authors into greater understanding of the topics taught. At times, it feels like the exercises are specifically designed to force you to think about the essence of the topics, and not just grasp them superficially.

SICP commonly suffers from the criticism that it's too hard for beginners. Maybe this criticism is rightful, and universities should give a simpler introductory course to programming before SICP. But this is an aspect of the educational systems, not pertaining to the book itself. I wouldn't know, I never read SICP as a beginner. However it is being taught, SICP is an amazing book. It is by far the best programming book I have ever laid by hands on, and I seriously doubt that it will be surpassed any time soon. Reading SICP will enlighten you as a programmer, and make you a better one. I can't imagine one programmer who won't gain something important by reading SICP.

SICP - conclusion

2008-04-18T16:54:27-07:00

I've completed the SICP reading project, which I began on June 19th, 2007. In hindsight, it seems like a very long time (almost a year!), during which this was my main hacking project at home. So, in this conclusion I want to examine my progress, and compare the result with my initial goals.

The original plan was:

Read the book
See all the video lectures by Sussman and Abelson themselves
Do most of the interesting exercises in the book
Do some of the larger projects listed here and here

Let's see how I've managed:

Done
Done
This is the point I'm most happy with. I've completed the vast majority of the exercises in SICP and posted them online. Of the 356 exercises in the book, I've skipped about 20, so I've completed 94% of the exercises – which is far above my initial plans.
I didn't do this, but there's no need, having completed so many of the exercises. I feel I gained a completely solid understanding of the material, and won't gain much by doing the projects.

Also, I originally planned to reimplement all the code do all the exercises in Common Lisp. Later I changed my mind and decided to use PLT Scheme for some of them. Eventually, I've been using both languages interchangeably, which is a good thing, as I got some practice with both.

Here are some numerical statistics that emphasize the magnitude of this endeavor:

I've written 52 blog posts (not including this one) in the SICP category, spread over 10 months.
The combined total length of my posts (including code snippets) is 66,265 words. For comparison, Jack London's "Son of the Wolf" is 50K words long.
Some of the large projects from the book I've re-implemented in wholeness: a constraint propagation solver, an evaluator (interpreter) for Scheme, a generic object-oriented arithmetic package including complex and polynomial arithmetic, Huffman encoding, an interpreter for a logic programming language similar to Prolog (as a DSL on top of Lisp), a picture-language interpreter, a simulator for digital circuits, a symbolic differentiation package, a virtual machine for a simplified pseudo-assembly DSL, an interpreter for Scheme written in this pseudo-assembly, and finally, a compiler for Scheme that spits out pseudo-assembly code.
Counting with the cloc tool (Count Lines Of Code), the total physical LOC count¹ for the code I've written during this time: 7,300 LOC of Common Lisp, 4,100 LOC of Scheme. If you prefer raw LOCs², it's 10,800 LOC of Common Lisp, 5,600 LOC of Scheme. So this is more than 10 KLOC of Lisp code, any way you look at it, which is a lot, since Lisp is a very expressive high-level functional language.

A word on SICP and its exercises. Abelson and Sussman have created a masterpiece, a book initially written in the 1980s, and that still hasn't lost one bit of relevance. Everything it contains must, must be learned and understood by any aspiring programmer. It teaches algorithms and data structures, good programming style, provides some contact with large systems, experimenting with their implementation and modification. You will learn about functional programming, imperative programming, object-oriented programming in it. You will learn how to implement interpreters, compilers, arithmetic systems, simulators, a whole virtual machine in it, and much more.

The exercises of SICP are essential to understanding. Looking back at the work I've done on the book, I don't think I would have understood it near so well without doing a lot of the exercises. There's only so much material that can be gained from reading. Getting your hands dirty with code is essential to true understanding. And the authors of SICP brought this concept to perfection, with their excellent exercises, that are an unreplaceable companion to the book. Although they're not 100% perfect, for the most part the exercises are very well thought out and tuned to aid understanding and practice writing parts of large systems.

¹ Physical LOC: lines of code, excluding comments and blank lines. To test my Common Lisp and Scheme code counts with cloc.pl, I used these commands:

cloc.pl --force-lang="Lisp",lisp *.lisp
cloc.pl --force-lang="Lisp",scm *.scm

² Including comments and blank lines, as output by wc -l.

SICP section 5.5

2008-04-18T12:17:37-07:00

It took me some effort to get the compiler code to work in conjunction with the explicit control evaluator, especially when it came to linking compiled and interpreted code. The prime problem was additions I've made to the register machine simulator in previous chapters, in answer to exercises, and that didn't work well with the needs of the compiler.

For example, in one of the exercises it was requested to test whether operations are being done on labels, and flag these cases as errors. However, in compile-lambda, the compiler creates this assignment:

`((assign ,target
    (op make-compiled-procedure)
    (label ,proc-entry)
    (reg env)))))

Note that it acts upon a label. So, I had to modify make-operation-exp and remove the error caused by operations on labels.

Another place where a change was needed is in lookup-variable-value, which, to answer an exercise, was modified to prepend bound or unbound to variables that were looked up. So I modified the code of compile-variable to:

(define (compile-variable exp target linkage)
  (end-with-linkage linkage
    (make-instruction-sequence '(env) (list target)
      `((assign ,target
                (op lookup-variable-value)
                (const ,exp)
                (reg env))
        (assign ,target
                (op var-val-extract-value)
                (reg ,target))))))

The addition is another assign which uses var-val-extract-value to extract the bound symbol values. As before the exercise, this code assumes that all the looked up variables are actually bound, and does not signal an error¹.

All the code required to run the compiler and execute the compiled code together with the explicit control evaluator on the register machine simulator can be downloaded in this bundle

In case you've missed it, consider what we have here. We have a compiler for Scheme, written in Scheme. This compiler spits out custom assembly code that executes on a register machine simulator, also written in Scheme. Moreover, this code can coexist with an interpreter for Scheme, written in the same assembly code. Isn't this just awesome ?

Anyway, since we now have all the infrastructure running, we're ready to tackle the exercises.

Exercise 5.31

(f 'x 'y) – all those saves and restores are superfluous, because looking up the operator and operands does not modify any registers.

((f) 'x 'y) – again, all the saves are superfluous. At first sight it might seem that (f) may modify the env register, so env must be saved. But note that env is not needed to evaluate the operands, since they are constants. Had the expression been ((f) x 'y), env should've been saved, because it's needed to evaluate the variable x.

(f (g 'x) y) – proc must be saved around the evaluation of the first operand, because it involves an application, which modifies proc. The application also modifies argl, so that one has to be saved too. env, however, needs not be saved. To understand why, recall that the compiler builds the argument list in reverse. So first it evaluates y, and only then (g 'x). Evaluating y does not modify env, so saving it isn't required.

(f (g 'x) 'y) – exactly similar to the previous case. Since the argument list is built in reverse, (g 'x) is constructed last, and there's really no difference in the effects of looking up y or 'y on the registers.

Exercise 5.32

The section beginning with ev-application has to be modified to:

ev-application
  (save continue)
  (assign unev (op operands) (reg exp))
  (assign exp (op operator) (reg exp))
  (test (op symbol?) (reg exp))
  (branch (label ev-appl-operator-symbol))
  (save env)
  (save unev)      
  (assign continue (label ev-appl-did-operator))
  (goto (label eval-dispatch))
ev-appl-operator-symbol
  (assign continue (label ev-appl-did-operator-no-restore))
  (goto (label eval-dispatch))
ev-appl-did-operator
  (restore unev)              ; the operands
  (restore env)
ev-appl-did-operator-no-restore
  (assign argl (op empty-arglist))
  (assign proc (reg val))     ; the operator
  (test (op no-operands?) (reg unev))
  (branch (label apply-dispatch))
  (save proc)

Note the test for symbol? that jumps over the saves, and assigns continue to a label that skips the restores.

Alyssa is wrong for two reasons.

Note that the test and branch inserted in the code of part a. does not come for free – it has to be executed for each operator, so the performance increase is less than expected. The compiler does its optimizations at compile-time, investing the time once but causing the code to run faster every time it's executed.
Another major reason for the compiler's speed advantage over the interpreter is "parsing" of expressions. The evaluator has to take the expression (+ 1 2) apart each time, figuring out that + is the operator and 1 and 2 the operands. The compiler does this step just once, and generates code that already knows where everything is located.

Exercise 5.33

The difference in the compiled code of the alternative is that it handles the invocation of the recursive call before evaluating n in the multiplication, while the original code first evaluates n.

Since the amount of instruction executed by each version of the compiled code is the same, I would expect the runtimes to be close to identical.

Exercise 5.34

Here's the compiled code, annotated with comments:

;; Construct the procedure and skip over code for
;; the procedure body
;;
  (assign val (op make-compiled-procedure) (label entry1) (reg env))
  (goto (label after-lambda2))
;; Entry point for calls to factorial
;;
entry1
  (assign env (op compiled-procedure-env) (reg proc))
  (assign env (op extend-environment) (const (n)) (reg argl) (reg env))
;; Construct the internal procedure 'iter'
;; 
  (assign val (op make-compiled-procedure) (label entry3) (reg env))
  (goto (label after-lambda4))
entry3
  (assign env (op compiled-procedure-env) (reg proc))
  (assign env (op extend-environment) (const (product counter)) (reg argl) (reg env))
  (save continue)
  (save env)
;; evaluate the 'if' predicate: (> counter n)
;;
  (assign proc (op lookup-variable-value) (const >) (reg env))
  (assign proc (op var-val-extract-value) (reg proc))
  (assign val (op lookup-variable-value) (const n) (reg env))
  (assign val (op var-val-extract-value) (reg val))
  (assign argl (op list) (reg val))
  (assign val (op lookup-variable-value) (const counter) (reg env))
  (assign val (op var-val-extract-value) (reg val))
  (assign argl (op cons) (reg val) (reg argl))
  (test (op primitive-procedure?) (reg proc))
  (branch (label primitive-branch8))
compiled-branch9
  (assign continue (label after-call10))
  (assign val (op compiled-procedure-entry) (reg proc))
  (goto (reg val))
primitive-branch8
  (assign val (op apply-primitive-procedure) (reg proc) (reg argl))
after-call10
  (restore env)
  (restore continue)
;; Test the 'if' predicate
;;
  (test (op false?) (reg val))
  (branch (label false-branch6))
;; In the true branch, evaluate and return 'product'
;;
true-branch5
  (assign val (op lookup-variable-value) (const product) (reg env))
  (assign val (op var-val-extract-value) (reg val))
  (goto (reg continue))
;; In the false branch, evaluate the application
;; of iter.
;;
false-branch6
  (assign proc (op lookup-variable-value) (const iter) (reg env))
  (assign proc (op var-val-extract-value) (reg proc))
  (save continue)
  (save proc)
  (save env)
;; Evaluate (+ counter 1)
;;
  (assign proc (op lookup-variable-value) (const +) (reg env))
  (assign proc (op var-val-extract-value) (reg proc))
  (assign val (const 1))
  (assign argl (op list) (reg val))
  (assign val (op lookup-variable-value) (const counter) (reg env))
  (assign val (op var-val-extract-value) (reg val))
  (assign argl (op cons) (reg val) (reg argl))
  (test (op primitive-procedure?) (reg proc))
  (branch (label primitive-branch14))
compiled-branch15
  (assign continue (label after-call16))
  (assign val (op compiled-procedure-entry) (reg proc))
  (goto (reg val))
primitive-branch14
  (assign val (op apply-primitive-procedure) (reg proc) (reg argl))
after-call16
  (assign argl (op list) (reg val))
  (restore env)
  (save argl)
;; Evaluate (* counter product)
;;
  (assign proc (op lookup-variable-value) (const *) (reg env))
  (assign proc (op var-val-extract-value) (reg proc))
  (assign val (op lookup-variable-value) (const product) (reg env))
  (assign val (op var-val-extract-value) (reg val))
  (assign argl (op list) (reg val))
  (assign val (op lookup-variable-value) (const counter) (reg env))
  (assign val (op var-val-extract-value) (reg val))
  (assign argl (op cons) (reg val) (reg argl))
  (test (op primitive-procedure?) (reg proc))
  (branch (label primitive-branch11))
compiled-branch12
  (assign continue (label after-call13))
  (assign val (op compiled-procedure-entry) (reg proc))
  (goto (reg val))
primitive-branch11
  (assign val (op apply-primitive-procedure) (reg proc) (reg argl))
after-call13
  (restore argl)
  (assign argl (op cons) (reg val) (reg argl))
  (restore proc)
  (restore continue)
  (test (op primitive-procedure?) (reg proc))
  (branch (label primitive-branch17))
;; The "recursive" call is done here.
;;
compiled-branch18
  (assign val (op compiled-procedure-entry) (reg proc))
  (goto (reg val))
primitive-branch17
  (assign val (op apply-primitive-procedure) (reg proc) (reg argl))
  (goto (reg continue))
after-call19
after-if7
;; After the body of the internal procedure,
;; we can compile the rest of the body of 
;; 'factorial'
;;
after-lambda4
;; Assign the variable 'iter' its procedure body
;;
  (perform (op define-variable!) (const iter) (reg val) (reg env))
  (assign val (const ok))
;; Execute (iter 1 1)
;;
  (assign proc (op lookup-variable-value) (const iter) (reg env))
  (assign proc (op var-val-extract-value) (reg proc))
  (assign val (const 1))
  (assign argl (op list) (reg val))
  (assign val (const 1))
  (assign argl (op cons) (reg val) (reg argl))
  (test (op primitive-procedure?) (reg proc))
  (branch (label primitive-branch20))
compiled-branch21
  (assign val (op compiled-procedure-entry) (reg proc))
  (goto (reg val))
primitive-branch20
  (assign val (op apply-primitive-procedure) (reg proc) (reg argl))
  (goto (reg continue))
after-call22
;; Now assign 
;;
after-lambda2
  (perform (op define-variable!) (const factorial) (reg val) (reg env))
  (assign val (const ok))

Note that nothing is saved before the recursive call to iter, in order to be restored later. It just jumps back to iter using (goto (reg val)). Contrary to the recursive case, where continue was assigned to just after the recursive call before executing it, here continue is just restored from the stack to its pre-call value. This is the essence of tail-call optimization.

Exercise 5.35

Following the code carefully, and remembering that the argument list is being built from right to left, it's not difficult to see that the Scheme code that compiled into this was:

(define (f x)
  (+ x (g (+ x 2))))

Exercise 5.36

The compiler produces right-to-left order of evaluation for operands of a combinations. This can be easily seen in the compiled code for (+ x y):

  (assign proc (op lookup-variable-value) (const +) (reg env))
  (assign proc (op var-val-extract-value) (reg proc))
  (assign val (op lookup-variable-value) (const y) (reg env))
  (assign val (op var-val-extract-value) (reg val))
  (assign argl (op list) (reg val))
  (assign val (op lookup-variable-value) (const x) (reg env))
  (assign val (op var-val-extract-value) (reg val))
  (assign argl (op cons) (reg val) (reg argl))
  (test (op primitive-procedure?) (reg proc))
  (branch (label primitive-branch1))
compiled-branch2
  (assign continue (label after-call3))
  (assign val (op compiled-procedure-entry) (reg proc))
  (goto (reg val))
primitive-branch1
  (assign val (op apply-primitive-procedure) (reg proc) (reg argl))
after-call3

Note the order of lookup-variable-value calls. y is first, x second.

The reason for this is also clear and was thoroughly explained in section 5.5.3 – "Compiling Combinations"

The code to construct the argument list will evaluate each operand into val and then cons that value onto the argument list being accumulated in argl. Since we cons the arguments onto argl in sequence, we must start with the last argument and end with the first, so that the arguments will appear in order from first to last in the resulting list.

In the compiler code, the culprit is function construct-arglist, which calls reverse on the list of operand codes before generating the actual code for them.

In order to modify the order to left-to-right, we'll need to move the reverse from compile-time to run-time. The instructions will be generated in left-to-right order, and reverse will be called on argl afterwards. Here's the modified construct-arglist that does the job:

(define (construct-arglist operand-codes)
  (let ((operand-codes operand-codes))
    (if (null? operand-codes)
      (make-instruction-sequence '() '(argl)
        `((assign argl (const ()))))
      (let ((code-to-get-last-arg
              (append-instruction-sequences
                (car operand-codes)
                (make-instruction-sequence '(val) '(argl)
                  `((assign argl (op list) (reg val)))))))
        (if (null? (cdr operand-codes))
          code-to-get-last-arg
          (tack-on-instruction-sequence 
            (preserving '(env)
              code-to-get-last-arg
              (code-to-get-rest-args
                (cdr operand-codes)))
            (make-instruction-sequence '() '()
              '((assign argl (op reverse) (reg argl))))))))))

Now the compiled code for (+ x y) will be:

  (assign proc (op lookup-variable-value) (const +) (reg env))
  (assign proc (op var-val-extract-value) (reg proc))
  (assign val (op lookup-variable-value) (const x) (reg env))
  (assign val (op var-val-extract-value) (reg val))
  (assign argl (op list) (reg val))
  (assign val (op lookup-variable-value) (const y) (reg env))
  (assign val (op var-val-extract-value) (reg val))
  (assign argl (op cons) (reg val) (reg argl))
  (assign argl (op reverse) (reg argl))
  (test (op primitive-procedure?) (reg proc))
  (branch (label primitive-branch1))
compiled-branch2
  (assign continue (label after-call3))
  (assign val (op compiled-procedure-entry) (reg proc))
  (goto (reg val))
primitive-branch1
  (assign val (op apply-primitive-procedure) (reg proc) (reg argl))
after-call3

This version of the compiler generates slower code, because the reverse now has to be performed at run-time, something that was spared before.

Exercise 5.37

The function preserving generates a save and restore for a register only if the first statement modifies a register the second one needs. By removing this condition, we can make preserving generate the instructions always:

(define (preserving regs seq1 seq2)
  (if (null? regs)
    (append-instruction-sequences seq1 seq2)
    (let ((first-reg (car regs)))
      (preserving (cdr regs)
        (make-instruction-sequence
          (list-union (list first-reg) (registers-needed seq1))
          (list-difference
            (registers-modified seq1)
            (list first-reg))
          (append 
            `((save ,first-reg))
            (statements seq1)
            `((restore ,first-reg))))
        seq2))))

Here's the compiled code for (f 1 2) with the original preserving:

  (assign proc (op lookup-variable-value) (const f) (reg env))
  (assign proc (op var-val-extract-value) (reg proc))
  (assign val (const 2))
  (assign argl (op list) (reg val))
  (assign val (const 1))
  (assign argl (op cons) (reg val) (reg argl))
  (test (op primitive-procedure?) (reg proc))
  (branch (label primitive-branch1))
compiled-branch2
  (assign continue (label after-call3))
  (assign val (op compiled-procedure-entry) (reg proc))
  (goto (reg val))
primitive-branch1
  (assign val (op apply-primitive-procedure) (reg proc) (reg argl))
after-call3

Note that no saves and restores are generated, because none are needed here (see solution for Exercise 5.31)

Now, the same expression with the modified preserving is compiled to:

  (save continue)
  (save env)
  (save continue)
  (assign proc (op lookup-variable-value) (const f) (reg env))
  (assign proc (op var-val-extract-value) (reg proc))
  (restore continue)
  (restore env)
  (restore continue)
  (save continue)
  (save proc)
  (save env)
  (save continue)
  (assign val (const 2))
  (restore continue)
  (assign argl (op list) (reg val))
  (restore env)
  (save argl)
  (save continue)
  (assign val (const 1))
  (restore continue)
  (restore argl)
  (assign argl (op cons) (reg val) (reg argl))
  (restore proc)
  (restore continue)
  (test (op primitive-procedure?) (reg proc))
  (branch (label primitive-branch1))
compiled-branch2
  (assign continue (label after-call3))
  (assign val (op compiled-procedure-entry) (reg proc))
  (goto (reg val))
primitive-branch1
  (save continue)
  (assign val (op apply-primitive-procedure) (reg proc) (reg argl))
  (restore continue)
after-call3

Exercise 5.38

a & b.

I'll add this new dispatch to compile:

((memq (car exp) '(+ - * / =))
  (compile-open-binary-op exp target linkage))

And the extra code is:

(define (spread-arguments a1 a2)
  (let ((ca1 (compile a1 'arg1 'next))
        (ca2 (compile a2 'arg2 'next)))
    (list ca1 ca2)))

(define (compile-open-binary-op exp target linkage)
  (if (= (length exp) 3)
    (let ((op (car exp))
          (args (spread-arguments (cadr exp) (caddr exp))))
      (end-with-linkage linkage
        (append-instruction-sequences
          (car args)
          (preserving '(arg1)
            (cadr args)
            (make-instruction-sequence '(arg1 arg2) (list target)
              `((assign ,target (op ,op) (reg arg1) (reg arg2))))))))
    (error "Expected a 3-element list -- COMPILE-OPEN-BINARY-OP" exp)))

Note that spread-arguments accepts strictly two arguments, because it has to place them in arg1 and arg2. Also, I made it return a normal list, rather than an instruction sequence. This is because the appropriate place what to preserve is compile-open-binary-op, that has 3 instruction sequences to append:

The evaluation of the first argument into arg1
The evaluation of the second argument into arg2, preserving arg1 because it will be needed later
The application of the operator to arg1 and arg2

Here are a couple of examples of code generated with these functions:

'(* 4 5)
=>
  (assign arg1 (const 4))
  (assign arg2 (const 5))
  (assign val (op *) (reg arg1) (reg arg2))
  (goto (reg continue))

(* 66 (+ 1 3))
=>
  (assign arg1 (const 66))
  (save arg1)
  (assign arg1 (const 1))
  (assign arg2 (const 3))
  (assign arg2 (op +) (reg arg1) (reg arg2))
  (restore arg1)
  (assign val (op *) (reg arg1) (reg arg2))
  (goto (reg continue))

Exercise 5.39

(define (make-lexaddr framenum displacement)
  (list framenum displacement))

(define (lexaddr-framenum lexaddr)
  (car lexaddr))

(define (lexaddr-displacement lexaddr)
  (cadr lexaddr))

; Note, the following two functions operate on the _runtime_
; environment, where each frame is a pair: list of variables 
; with a list of their values.
;
(define (lexical-address-lookup lexaddr rt-env)
  (let ((addr-frame (list-ref rt-env (lexaddr-framenum lexaddr))))
    (let ((addr-val (list-ref (frame-values addr-frame) (lexaddr-displacement lexaddr))))
      (if (eq? addr-val '*unassigned*)
        (error "Var is unassigned"))
        (cons 'bound addr-val))))

(define (lexical-address-set! lexaddr rt-env newval)
  (let ((addr-frame (list-ref rt-env (lexaddr-framenum lexaddr))))
    (define (iter vals count)
      (cond ((null? vals)
              (error "Invalid lexical address - bad displacement"))
            ((= count 0)
              (set-car! vals newval))
            (else (iter (cdr vals) (+ 1 count)))))
    (iter (frame-values addr-frame) (lexaddr-displacement lexaddr))))

Exercise 5.40

The full code for this section, including the modified compiler, can be downloaded here

He're the code generator for lambda, which extends the compile-time environment:

(define (compile-lambda-body exp proc-entry ct-env)
  (let ((formals (lambda-parameters exp)))
    (append-instruction-sequences
      (make-instruction-sequence '(env proc argl) '(env)
        `(,proc-entry
          (assign env (op compiled-procedure-env) (reg proc))
          (assign env
                  (op extend-environment)
                  (const ,formals)
                  (reg argl)
                  (reg env))))
      (compile-sequence 
        (lambda-body exp) 
        'val 'return 
        (extend-ct-env ct-env formals)))))

It uses this utility function:

(define (extend-ct-env ct-env frame)
  (cons frame ct-env))

Exercise 5.41

(define (find-variable var ct-env)
  (define (frame-iter var frames count)
    (if (null? frames) 
      '()
      (let ((var-index (index-in-list 
                        (lambda (i) (eq? i var))
                        (car frames))))
        (if (null? var-index)
          (frame-iter var (cdr frames) (+ count 1))
          (make-lexaddr count var-index)))))
  (frame-iter var ct-env 0))

; Returns the numerical index (0-based) of the first 
; item from the list that satisfies the predicate.
; If no suitable item is found, returns '()
;
(define (index-in-list pred lst)
  (define (iter pred lst count)
    (cond
      ((null? lst) '())
      ((pred (car lst)) count)
      (else (iter pred (cdr lst) (+ count 1)))))
  (iter pred lst 0))

Exercise 5.42

To understand how this works, it's important to keep in mind that the structure of the compile-time environment follows the structure of the run-time environment. The compiler, by knowing where inside the stack of lambda statements it's located, can figure out which value is referenced in the code.

(define (compile-variable exp target linkage ct-env)
  (let ((lookup-instruction 
          (let ((lexaddr-of-var (find-variable exp ct-env)))
            (if (null? lexaddr-of-var)
              `(assign ,target
                        (op lookup-variable-value)
                        (const ,exp)
                        (reg env))
              `(assign ,target
                        (op lexical-address-lookup)
                        (const ,lexaddr-of-var)
                        (reg env))))))
    (end-with-linkage linkage
      (make-instruction-sequence '(env) (list target)
        (list
          lookup-instruction
          `(assign ,target
                  (op var-val-extract-value)
                  (reg ,target)))))))

(define (compile-assignment exp target linkage ct-env)
  (let ((var (assignment-variable exp))
        (get-value-code
          (compile (assignment-value exp) 'val 'next ct-env)))
    (end-with-linkage linkage
      (preserving '(env)
        get-value-code
        (make-instruction-sequence '(env val) (list target)
          (let ((lexaddr-of-var (find-variable var ct-env)))
            (if (null? lexaddr-of-var)
              `((perform 
                  (op set-variable-value!)
                  (const ,var)
                  (reg val)
                  (reg env))
                (assign ,target (const ok)))
              `((perform
                  (op lexical-address-set!)
                  (const ,lexaddr-of-var)
                  (reg env)
                  (reg val))
                (assign ,target (const ok))))))))))

Here's an example that demonstrates how these modifications work. This code:

(define code
  '((lambda (x y) 
      (lambda (u v w)
        (set! x 60)
        (+ v w x))
      10 20 30)
    1 2)
)

Is compiled into:

  (assign proc (op make-compiled-procedure) (label entry1) (reg env))
  (goto (label after-lambda2))
entry1
  (assign env (op compiled-procedure-env) (reg proc))
  (assign env (op extend-environment) (const (x y)) (reg argl) (reg env))
  (assign val (op make-compiled-procedure) (label entry3) (reg env))
  (goto (label after-lambda4))
entry3
  (assign env (op compiled-procedure-env) (reg proc))
  (assign env (op extend-environment) (const (u v w)) (reg argl) (reg env))
  (assign val (const 60))
  (perform (op lexical-address-set!) (const (1 0)) (reg env) (reg val))
  (assign val (const ok))
  (assign proc (op lookup-variable-value) (const +) (reg env))
  (assign proc (op var-val-extract-value) (reg proc))
  (assign val (op lexical-address-lookup) (const (1 0)) (reg env))
  (assign val (op var-val-extract-value) (reg val))
  (assign argl (op list) (reg val))
  (assign val (op lexical-address-lookup) (const (0 2)) (reg env))
  (assign val (op var-val-extract-value) (reg val))
  (assign argl (op cons) (reg val) (reg argl))
  (assign val (op lexical-address-lookup) (const (0 1)) (reg env))
  (assign val (op var-val-extract-value) (reg val))
  (assign argl (op cons) (reg val) (reg argl))
  (test (op primitive-procedure?) (reg proc))
  (branch (label primitive-branch5))
compiled-branch6
  (assign val (op compiled-procedure-entry) (reg proc))
  (goto (reg val))
primitive-branch5
  (assign val (op apply-primitive-procedure) (reg proc) (reg argl))
  (goto (reg continue))
after-call7
after-lambda4
  (assign val (const 10))
  (assign val (const 20))
  (assign val (const 30))
  (goto (reg continue))
after-lambda2
  (assign val (const 2))
  (assign argl (op list) (reg val))
  (assign val (const 1))
  (assign argl (op cons) (reg val) (reg argl))
  (test (op primitive-procedure?) (reg proc))
  (branch (label primitive-branch8))
compiled-branch9
  (assign val (op compiled-procedure-entry) (reg proc))
  (goto (reg val))
primitive-branch8
  (assign val (op apply-primitive-procedure) (reg proc) (reg argl))
  (goto (reg continue))
after-call10

Note how the relevant variables are accessed using lexical-address-lookup, where applicable.

Exercise 5.43

The change required here is very simple. compile-lambda-body is modified to execute scan-out-defines on the lambda body before passing it on to compilation:

(define (compile-lambda-body exp proc-entry ct-env)
  (let ((formals (lambda-parameters exp)))
    (append-instruction-sequences
      (make-instruction-sequence '(env proc argl) '(env)
        `(,proc-entry
          (assign env (op compiled-procedure-env) (reg proc))
          (assign env
                  (op extend-environment)
                  (const ,formals)
                  (reg argl)
                  (reg env))))
      (compile-sequence 
        (scan-out-defines (lambda-body exp))  ;; change!
        'val 'return 
        (extend-ct-env ct-env formals)))))

The rest of section 5.5

I think I'll skip the rest of the exercises.

¹ Although such error signaling shouldn't be difficult to add.

SICP section 5.4

2008-04-04T08:39:25-07:00

When I began writing the explicit-control evaluator code for this section, I ran into a minor language incompatibility. While I've used CL to implement the meta-circular evaluator of chapter 4, I've employed Scheme for the implementation of the register machine simulator earlier in this chapter. This means that I can't use the meta-circular evaluator's primitive functions directly in my register-machine code.

So I've downloaded the code from chapter 4 of the book from here. The specific file that is included in my code is this one – I've cleaned it up and modified it a little to be compatible with PLT Scheme, and provide only the required functionality.

The explicit-control evaluator itself is available here. I've modified it a little, adding some functionality for non-interactive evaluation. Specifically, this code:

non-interactive-eval
  (perform (op initialize-stack))
  (test (op null?) (reg machine-args))
  (branch (label machine-end))
  (assign exp (op car) (reg machine-args))
  (assign machine-args (op cdr) (reg machine-args))
  (assign env (op get-global-environment))
  (assign continue (label non-interactive-eval))
  (goto (label eval-dispatch))

Can be jumped to instead of read-eval-print-loop. It assumes there is a list of expressions to be evaluated in the machine-args register, and goes over them, evaluating them from left to right. This allows for convenient execution of the evaluator as follows:

(define code
  '(
    (define (sumsq a b)
      (+ (* a a) (* b b)))
    (define x 5)
    (define y 7)
    (define ans (sumsq x y))
    (print ans)
    ))

(set-register-contents! ec-eval 'machine-args code)
(start ec-eval)
=>
74

You'll also see in the beginning of the controller code these two lines:

  ; (goto (label read-eval-print-loop))
  (goto (label non-interactive-eval))

Currently the jump to read-eval-print-loop is commented, but this can be easily changed.

Another change you'll note in the definition of the machine's operations. I got tired of writing each operator name twice (once quoted, and once plain), and wrote the macro¹ qq to handle it for me:

(define-macro (qq e)
  `(list ',e ,e))

For example, (qq adjoin-arg) gets translated in "compile-time" into (list 'adjoin-arg adjoin-arg) so I have less repetitive typing to do.

Exercise 5.23

Adding support for cond:

ev-cond
  (assign exp (op cond->if) (reg exp))
  (goto (label ev-if))

And the appropriate dispatch is:

(test (op cond?) (reg exp))
(branch (label ev-cond))

Finally, to make it all work the operations cond? and cond->if must be added to the machine.

Exercise 5.24

Here's the code:

  ;; Implemented explicitly as a basic special form, 
  ;; without converting to a nested if
  ;;
ev-cond-basic
  (assign unev (op cond-clauses) (reg exp))
ev-cond-ev-clause
  (assign exp (op first-exp) (reg unev))
  (test (op cond-else-clause?) (reg exp))
  (branch (label ev-cond-action))
  (save exp)
  (save env)
  (save unev)
  (save continue)
  ;; Setup an evaluation of the clause predicate
  (assign exp (op cond-predicate) (reg exp))
  (assign continue (label ev-cond-clause-decide))
  (goto (label eval-dispatch))

ev-cond-clause-decide
  (restore continue)
  (restore unev)
  (restore env)
  (restore exp)
  (test (op true?) (reg val))
  (branch (label ev-cond-action))
ev-cond-next-clause
  (assign unev (op rest-exps) (reg unev))
  (goto (label ev-cond-ev-clause)) ; loop to next clause

  ;; We get here when the clause condition was found to
  ;; be true (or it was an 'else' clause), and we want
  ;; the actions to be evaluated. The clause is in exp.
  ;; We setup a call to ev-sequence and jump to it.
  ;;
ev-cond-action
  (assign unev (op cond-actions) (reg exp))
  (save continue)
  (goto (label ev-sequence))

Now eval-dispatch can jump to ev-cond-basic:

  (test (op cond?) (reg exp))
  (branch (label ev-cond-basic))

Exercise 5.25

I'll pass.

Exercise 5.26

To make this work, I've re-included the modified make-new-machine and make-stack from exercise 5.14, and removed the command to reinitialize the stack after each executed expression in non-interactive-eval. The code I'm running is:

(define code
  '(
    (define (factorial n)
      (define (iter product counter)
        (if (> counter n)
            product
            (iter (* counter product)
                  (+ counter 1))))
      (iter 1 1))

    (newline)
    (print (factorial 3))
    (newline)
  ))

(set-register-contents! ec-eval 'machine-args code)
(start ec-eval)

(newline)
(newline)

a. The maximal depth required for this code is 13

n	pushes
2	113
3	148
4	183
5	218

From this, the number of pushes is 35n + 43.

Exercise 5.27

Type	Maximal depth	Number of pushes
Recursive	5n + 6	32n – 2
Iterative	13	35n + 43

Exercise 5.28

After changing ev-sequence to:

ev-sequence
  (test (op no-more-exps?) (reg unev))
  (branch (label ev-sequence-end))
  (assign exp (op first-exp) (reg unev))
  (save unev)
  (save env)
  (assign continue (label ev-sequence-continue))
  (goto (label eval-dispatch))
ev-sequence-continue
  (restore env)
  (restore unev)
  (assign unev (op rest-exps) (reg unev))
  (goto (label ev-sequence))
ev-sequence-end
  (restore continue)
  (goto (reg continue))

The table of exercise 5.27 turns into:

Type	Maximal depth	Number of pushes
Recursive	8n + 6	34n – 2
Iterative	3n + 17	37n + 47

Exercise 5.29

n	depth
2	16
3	21
4	26
5	31

From this, the formula for depth is 5n + 6.

Let's collect some more data for this:

n	pushes
2	86
3	142
4	254
5	422
6	702
7	1150
8	1878

It can be easily seen that S(n) = S(n-1) + S(n-2) + 26.

To find out a and b, I'll subtract S(n) from S(n+1) to cancel out b: S(n+1)-S(n) = a*Fib(n+2) - a*Fib(n+1) = a*(Fib(n+2) - Fib(n+1)). But due to the property of the Fibonacci series, this means that: S(n+1)-S(n) = a*Fib(n). And since S(n) = S(n-1) + S(n-2) + 26, we can rewrite it as a*Fib(n-1) = S(n-2) + 26, or S(n) = a*Fib(n+1) - 26.

Now we're ready to assign the various results into this to compute a. Having the formula and b in our hands, it's easy to see that a = 56.

So, finally: S(n) = 56Fib(n+1) - 26

Exercise 5.30

a. Maybe I'm missing something, but this doesn't seem to be so much work. After all, a variable is only handled in a single place in the eval dispatch, so this is the place to make a modification. First of all, I'll change the supporting Scheme code to have special values for unbound variables:

(define (lookup-variable-value var env)
  (define (env-loop env)
    (define (scan vars vals)
      (cond ((null? vars)
              (env-loop (enclosing-environment env)))
            ((eq? var (car vars))
              (cons 'bound (car vals)))
            (else (scan (cdr vars) (cdr vals)))))
    (if (eq? env the-empty-environment)
        (cons 'unbound '())
        (let ((frame (first-frame env)))
          (scan (frame-variables frame)
                (frame-values frame)))))
  (env-loop env))

(define (var-val-bound? varval)
  (and 
    (pair? varval) 
    (eq? (car varval) 'bound)))

(define (var-val-extract-value varval)
  (cdr varval))

Now, changing ev-variable in the evaluator code:

ev-variable
  (assign val (op lookup-variable-value) (reg exp) (reg env))
  (test (op var-val-bound?) (reg val))
  (branch (label ev-variable-var-bound))
  (goto (label unbound-variable))
ev-variable-var-bound
  (assign val (op var-val-extract-value) (reg val))
  (goto (reg continue))

And finally, a new error type:

unbound-variable
  (assign val (const unbound-variable-error))
  (goto (label signal-error))

b. Well, this indeed is a lot of work, and it's very repetitive, so I'm reluctant to do it. The basic model is identical to what I've written in part a of this question.

Each primitive that can signal an error must be modified similarly to the way lookup-variable-value was modified, to return a pair of (error? value), with the appropriate support procedures. The evaluator code in primitive-apply must check for the error, similarly to the modified ev-variable in the code above.

¹ Personally, I like the define-macro utility more than the Scheme's syntax-rules and syntax-case macro tools. define-macro is almost identical to Common Lisp's defmacro and is natively supported by the most common Scheme implementations (Bigloo, Chicken, Gambit, Gauche and PLT Scheme). To use it in PLT Scheme you'll have to include the defmacro.ss library:

(require (lib "defmacro.ss"))