Kenny Tilton writes:
Thomas F. Burdick wrote:
(defmodel adder () ((x :accessor adder-x :initform (cv)) (y :accessor adder-y :initform (cv)) (sum :accessor adder-sum :initform (c? (+ (^adder-x) (^adder-y))))))
(defparameter >>adder (to-be (make-instance 'adder)))
(setf (adder-x >>adder) 0)
The above happily works. It doesn't trigger the rule until I do:
(adder-sum >>adder) => <unbound-cell error>
Add: (def-c-echo sum () (print (list self new-value old-value)))
...and you'll get the error when to-be runs.
Hmm, I get the error once. That is:
(to-be (make-instance 'adder)) => <error> (to-be (make-instance 'adder)) => ADDER
I added your code. My c-install had evolved a little, so I just added the make-unbound.
Cool. What I sent should be fine alone, it has the capabilities of the hack I'd been using. However, it would be cool to keep going, and have support for making slots unbound:
I see you /had/ handle things on the read side, so I am trying to remember what we had talked about on the propagation side:
need to be made: cells doesn't currently catch the unbound-cell errors, because I wasn't sure where in the propagation code to put it.
The above is confusing. Cells (with your additions) certainly does catch reads of unbound cells, as you noted once you accessed adder-sum.
I meant "doesn't handle conditions of type CELLS:UNBOUND-CELL". This doesn't come up in what I have so far, because of the nascent-cells thing that was throwing me. But, let's say we add a method on SLOT-MAKUNBOUND-USING-CLASS (or add a c-slot-makunbound function). If I call (slot-makunbound >>adder 'x), it should set X back to being unbound, and kick off the rule for SUM.
At this point, something should handle the UNBOUND-CELL error, and make SUM unbound. Now, if I call ADDER-SUM, it should kick off SUM's rule again, and this time raise the UNBOUND-CELL error for X. I hadn't yet tried to figure out where to establish a handler for UNBOUND-CELL, because I was tripped out by my little example above.
capite?