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

[Peter Hildebrandt]

On Sun, Apr 13, 2008 at 5:21 PM, Ken Tilton <kennytilton at optonline.net> wrote:

>  Right, thanks, sorry for the head fake. Eventually something should be
> added to the regression test.

Well, we don't want to end up with more lines of test code than
program code.  So I'd leave that to the debugger for now ;-)

> > I am not quite sure about the implications, though.
>
>  Yeah, it is not clear what to do. The instance is no longer part of the
> model, so some rules will outright fail and those that do not would possibly
> be circular or at least form crazy dependencies of things no longer extant
> on those that are.

I assume that c-value is at least safe (that is, it is bound to return
*something*) to do, so the only issue we're facing is that the value
might be old.

So my question becomes:  How old can the value in the c-value slot
become?  I do not understand cells well enough to know whether we can
safely assume that every change (setf) from before the changing of the
kids list has trickled down to every ruled cell *before* not-to-be
gets called as a result of a (distinct) change to the kids slot.  I
assume it would, though.

It is trickier if the change to one input cell through a bunch of
dependencies leads to a change in the kids list of some family member.
 Then not-to-be gets called, and we have no way of being sure which
consequences of the original change have already been propagated and
which haven't.

But then, again, the value in c-value should be a max of one change
old, that is, it should reflect the correct value from before the
change which affected the kid to get thrown out.

And now I realize I have just reinvented what  you wrote.  Damn, I
should read the whole message *before* responding.

>  Hmmm. I see 'not-to-be gets called pretty early, pretty much as soon as a
> slot value has changed and owned things are seen to be no longer in that
> slot, right during propagation. So where a dying instance reads slot X and
> slot X is still alive and would normally update when read (and still will
> later during this same propagation (I think <g>)) then the dying instance
> will see either an obsolete value or (I just realized) a new value if
> propagation got to X first by another path.
>
>  Nothing like a little non-determinism to start the day. :)
>
>  Well, The Lisp Way is to let people shoot themselves in the foot, we can
> probably just leave it as it is and see what happens.

Agreed.  Especially since I feel the situations in which that could
cause a problem are academic in nature.  Usually not-to-be will only
be concerned with cleanup stuff, and the cell values which are needed
therefore would normally be somewhat stable, I assume.

So if it will actually become an issue, we can still go back and
invent the :death-bed stage in which not-to-be's are called after all
changes have been propagated.

>  If there was any documentation we could document not-to-be and point all
> this out and remind them that code in not-to-be should not be doing things
> in or with the model, it should be, eg, notifying C libraries that blocks
> they allocated can be scavenged.

I guess the cells-devel archives serve as a doc in some way, so by
that logic it is already part of the documentation.

>  Hmmm, those /could/ be the result of Cell rules, I guess it is good to
> return the old value.

This is hard now.  Because it implies that *no* changes should be
propagate dbefore not-to-be is called.  But how to do that?  Build a
queue for *all* changes, filter out the changes to the kids, call
not-to-be on the old, intact model, then propagate the changes from
the queue?  And what if not-to-be inflicts changes?  My head is
spinning ... I have to wait until after I have finished that bottle of
wine.

Cheers,
Peter