[cells-devel] I think it's a bug [was SOME vs The Ephemerals]

[Ken Tilton]

Ken Tilton wrote:

> If you have been following the drama, i broke Lars's chat log with 
> this rule (somewhat revised):
>
>   (chat-log:accessor chat-log
>         :initform (c? (concatenate 'string
>                             (or .cache "")
>                             (some 'speech-of (participants-of self)))))
>
> SOME stops at the first non-nil speech, establishing no dependencies 
> on the speech of any participant farther down the "participants-of" list.
>
> This is a problem, because speech-of is an ephemeral. It gets set to 
> nil /without/ propagating after any non-nil value gets set and 
> propagated. That is what ephemerals are all about, and I think that 
> much is solid....... maybe not. We'll come back to this. Anyway, if 
> someone farther down the list now says something, the rule does not 
> run because it has no dependency on their speech. And the log misses 
> an entry.
>
> Now I could just call this a user error ("Hey, Kenny! No dependency, 
> no re-calc!") and wipe my hands of the whole mess, but I have been 
> doing Cells for ten years and I had to debug in the internals for the 
> first time in a lonnng time to figure this one out, so I think an 
> unwritten law is being violated: normal, healthy Lisp code should 
> transparently maintain dependencies automatically.
>
> deep background: if there is no way around this, so be it, we have an 
> entry for a "gotchas" FAQ. But one thing that ruins supercool 
> libraries is exactly this sort of violation of the principle of least 
> surprise. So I want to see if the above code can be made to work.
>
> What I was thinking (until just now) was that any time a rule 
> encountered an ephemeral, just after the ephemeral got reset, the rule 
> should be rerun just to establish dependencies, not for its value. The 
> code would be simple (famous last words): after resetting an 
> ephemeral, iterate over all dependents of the ephemeral and call their 
> rule, ignoring the return value. Weird, but I bet it works.
>
> The alternative is to implement the "reset ephemeral step" actually as 
> a proper datapulse in which the ephemeral is set to NIL. Full 
> propagation, including observers of the ephemeral. Boy, that sure 
> weakens the ephemerality metaphor. :)
>
> Thoughts? Meanwhile, I will canvas real-world uses of ephemeral cells 
> for inspiration.

nah, that was too much like work. It was not just "track down 
ephemerals", it mean looking at every cell that used every ephemeral.

to hell with it, I fell back on Deep Theory: the idea of an ephemeral is 
to revert after being set to a state prior to having been set. Seems to 
be that this SOME problem simply makes the point that not only must the 
value mediated be reset to NIL, but also that dependent Cells have the 
dependencies they had when the value was nil. That is almost a 
no-brainer now that I put it that way.

Made the change (it was trivial), regression test ran without a 
complaint and the SOME bug went away without further fuss.

Life is good, except I think I saw that non-nil initialization of an 
ephemeral did not work ... i thought that did work, though quite 
recently it was unsupported. Gotta look at that next.

kenny

-------------- next part --------------
A non-text attachment was scrubbed...
Name: kentilton.vcf
Type: text/x-vcard
Size: 171 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/cells-devel/attachments/20060613/ac958d18/attachment.vcf>