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