Answer 3.32

ex-3_28-32.scm

@@ -19,8 +19,8 @@
                  (call-each action-procedures))
           'done))
     (define (accept-action-procedure! proc)
-      (set! action-procedures (cons proc action-procedures)))
+      (set! action-procedures (cons proc action-procedures))
-;      (proc))
+      (proc))
     (define (dispatch m)
       (cond ((eq? m 'get-signal) signal-value)
             ((eq? m 'set-signal!) set-my-signal!)
@@ -202,6 +202,7 @@
 
 
 (display "\nex-3.31 - accept-action-procedure!\n")
+(display "[see comment]\n")
 
 (define input-1 (make-wire))
 (define input-2 (make-wire))
@@ -227,4 +228,28 @@
 ; one.
 
 (display "\nex-3.32\n")
+(display "[see comment]\n")
+
+(define input-1 (make-wire))
+(define input-2 (make-wire))
+(define out (make-wire))
+(and-gate input-1 input-2 out)
+; (probe 'out out)
+
+(set-signal! input-1 0)
+(set-signal! input-2 1)
+(propagate)
+(assert (get-signal out) 0)
+
+(set-signal! input-1 1)
+(set-signal! input-2 0)
+(propagate)
+(assert (get-signal out) 0)
+
+; Executing the queued action items out of order could lead to unexpected
+; states. In the example above, if we set input-1 to 1 first, and then input-2
+; to 0, we would expect the output to change to 1 for one and-gate-delay. If we
+; probe the output signal we can see that this is indeed what happens. Now, if
+; the actions would not be processed in FIFO order, the output would never
+; switch to 1.
 

ex-3_33-xx.scm

@@ -0,0 +1,5 @@
+(load "util.scm")
+
+(display "\nexample - propagation of constraints\n")
+
+(display "\nex-3.33\n")