On Sun, Apr 13, 2008 at 5:21 PM, Ken Tilton kennytilton@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