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

[Kenny Tilton]

Thomas F. Burdick wrote:

>Kenny Tilton writes:
> >  if you want to send me something with these two amendments I will 
> > manually merge with the Cells I have here, currently a subdirectory of 
> > Cello, and then future Cello/Cells releases will have that. I guess I am 
> > still leaning towards that structure, in which Cells can be accessed 
> > indepenendently but from within the larger Cello context.
>
>Coolio, let's get it in CVS, over in Cello-land, then.
>
ah, yes, cvs. i was functional in that for a day a few months ago. not 
sure when that comet comes around again. i would invite you to put up 
PC4, but I did something I regret to defmodel, so that has to come out. 
the prior version would suffice. if you feel brave, go for it, or I will 
do so on the next orbit.

>
>I tried to add unbound-cells support to Cells itself, and I think it
>works, but I wasn't expecting it to.  In short:
>
>  (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>
>
>Am I crazy, or shouldn't it have given me that when I set adder-x to
>0? 
>
No, you are not crazy, it is just a subtlety even I can forget after all 
these years of celling:

1) The dependency of sum on adder which would cause sum to be 
reevaluated does not exist until sum gets evaluated.
2) ruled cells get artificially evaluated into existence at 
make-instance time if and only if they have echo functions defined on 
them. why? the echos are the only reason for the jump-start evaluation, 
and I once was able to benefit massively from this reticence, and it 
offers an opportunity for efficiency--ie, it's a little weird, but I 
like it.

ergo) if you inspected >>adder's .cells you would discover sum's cell is 
in a nascent state and has no dependencies. come to think of it, you 
/know/ it has no dependency on adder-x because that could only arise 
from the rule running, which would have yielded an unbound error.

> Even if I am crazy, and that should work fine, one change does
>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.
>
I do not think it is a propagation issue. The error should arise iff an 
unbound cell/slot gets read. So in md-slot-value:

    ; also work, but we need to document this very specific order of 
operations
    ; anyway, can't just leave that to the left-right thing.
    ;
    (let ((slot-value (etypecase slot-c
                        (null (bd-slot-value self slot-spec))
                        (c-variable (c-value slot-c)) <================ 
test here for unbounditude
                        (c-ruled (c-ruled-slot-value slot-c)))))

Mind you, this is off the top of my head and I have just returned from 
another successful (hic!) lisp-nyk meeting, but I think this is right.

It /would/ be possible for a propagation to a ruled cell to cause 
evaluation to branch in a new direction such that it then read an 
unbound cell, but that is still a failure at read-time, I think.

kt