[cells-devel] Handling not-to-be'd kids and how to do an input slot for kids

[Ken Tilton]

Peter Hildebrandt wrote:
> Ken,
> 
> as discussed in the ECLM thread:
> 
> 
>> I look forward to the IR, maybe you have run into something I want to add
>>to Cells to better handle things going away (a frequent problem). In my
>>latest app I am running into a lot of problems with what is generally called
>>referential integrity, specifically external references to kids that have
>>been not-to-be'd. eg, my window's keep a reference to the "focus", which
>>might be in a math problem the student decides to delete.  uh-oh. Sprinkling
>>(setf (focus w) nil) all over the place broke down when it ended up erasing
>>a new value that had been set by code that tried to handle the problem by,
>>say, moving the focus to the next problem when deleting the current problem.
> 
> 
> What happens in my case is that I have one family observing another like
> 
> (defmodel observer (family)
>   ()
>   (:default-initargs :kids (kids-list? (loop for kid in (kids (value
> self)) collecting (make-instance 'observer :value kid :fm-parent
> *parent*)))))
> 
> Then, when we remove a kid in the observed tree, its kids are declared
> md-dead *before* the observers on those are disposed of, and
> immediately cells complains about accessing a dead cell.
> 
> I am at a loss here, so any insight is greatly appreciated.

I was thinking while doing the dishes. I can image the observer class 
being interesting in its own right, and slots over there ending up 
dependent on the same original kids-list in some way, as well of course 
as the value of the observer. Propagation would then try to update this 
slot and when it got to the value of the observer find a dead instance. 
Any rule that got to the value of the observer by accessing the list of 
observers (say something iterating over them) would not encounter such 
an observer/value, but rules lower down that get at the value directly 
will.

Now normally this is not a problem because such lower down rules would 
tend not to depend also on the original list, and indeed the reason I 
have left this unaddressed is that in most cases I have seen a simple 
way to rewrite my rules that was even better and which did not end up 
with these widespread dependencies (if you have followed me so far on 
that, and if I hasten to add all this guesswork is on the money). I like 
to hold out for Real Problems before whacking away at the code, I think 
that is a slippery slope.

btw, all that stuff in their that worries about dead instances is 
preemptive safeguard stuff -- I think if you disable that most things 
will just work. The rules that are failing now will run harmlessly and 
in a few cycles everything gets cleaned up anyway. Cells ran for /years/ 
with this happening to no ill effect (until RoboCup, of all things).

If you want to send me your whole project I will look to see how I would 
rewrite the rules if that is even possible, and if not take a look at 
solving this formally.

fyi, in the past I have done silly things like having Cells just return 
nil on slot-value access to dead cells, but we may want to find 
something more elegant. :)

kt