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

[Ken Tilton]

Peter Hildebrandt wrote:
> 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 ;-)

Not an XP fan? :) Cells is pretty stable (but that will come unglued if 
people like you and Andy keep showing up) but I love taking things that 
go wrong and throwing them into a regression test suite precisely so I 
can continue hacking like a cowboy and then just re-running the test to 
see what broke, and if nothing breaks the code is declared perfect cuz 
if there is any behavior one does not like one has to get into the 
regression test.

I know the XP guys write the tests first -- that might be a good policy 
for RFEs: if someone wants something changed they have to specify it in 
the form of a test that will not pass now. Just a great exercise for 
clarifying what one wants, seeing if it might already be there, and 
doing so in a way that guarantees no future change will back it out.

(Sorry, just thinking out loud here.)


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

Ah, I was wondering why you were surprised that 3 had gotten through. A 
naked SETF ends up wrapped in a within-integrity call that ensures data 
integrity as defined in cells-manifesto.txt (half-way in look for a list 
of a half-dozen things defining "integrity"). I think that will clarify 
things greatly.


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

Right, a new :ex-parrot unfinished-business queue to be processed before 
  (I suppose) looking for a new change perhaps kicked off by an observer.

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

Right, it's a lost cause. The Real Problem is not clearly dividing 
model-time from non-model-time by doing anything modelly during 
not-to-be. It was a bit extreme (as I once had it and did again by 
mistake) to force... ha, maybe that /is/ the way to go, force them to 
use slot-value. I like things like that that say to the user "I do not 
think you will forget you are in not-to-be as long as only slot-value works.

Anyway...

kt