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
begin:vcard
fn:Kenneth Tilton
n:Tilton;Kenneth
email;internet:[EMAIL PROTECTED]
tel;work:732-359-6038
tel;home:732-359-6038
tel;cell:646-269-1077
version:2.1
end:vcard
_______________________________________________
cells-devel site list
[email protected]
http://common-lisp.net/mailman/listinfo/cells-devel
