[cells-devel] Re: [cello-devel] Constructor syntax

[Kenny Tilton]

Thomas F. Burdick wrote:

>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
>
Shut up! I can't wait to see this one. Gotta run out for a sec, but I'll 
look at this in a bit.

>
> > 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:
>
ok, that's where I thought you were going.

>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.
>
right.

>
>At this point, something should handle the UNBOUND-CELL error, and
>make SUM unbound.
>
well, I always get a kick out of digging and digging and finally there 
it is in all its simplicity:

    (funcall (c-rule c) self)

...or something like that. So that would be where the trap for 
unbounditude would go.

>  Now, if I call ADDER-SUM, it should kick off SUM's
>rule again,..
>
Why? rules get run when dependencies change or the state is unknown 
(only after make-instance, except for lazy cells which have been 
invalidated but not recalculated). The unbounditude is effectively a 
cached result, so there is no need to kick off the rule.

> 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?
>
>  
>
kt