[cells-devel] Optimized away/dying rules

[Ken Tilton]

That was fuzzy. Clarifications below...

On Mon, Apr 21, 2008 at 8:31 PM, Ken Tilton <kennytilton at optonline.net>
wrote:

> Peter Hildebrandt wrote:
>
> > Ken,
> >
> > thanks again for the info.  I guess some stuff got out of order here:
> >
> >
> >  First, just a point of information: do I understand correctly that the
> > > original example below uses an assoc instead of your store just to
> > > simplify
> > > the problem and highlight the key issue?
> > >
> >
> >
> > Yes and no.  Yes, the list stuff was my attempt of singling out what
> > was going on.  But! -- I wrote the stuff *before* I understood the
> > issue; in other words, this is how I tried (!) to do it before I made
> > the cells store.
> >
> >
> >
> >  I am guessing yes, so I will charge ahead with my thoughts: basically
> > > you
> > > need to make the lookup itself establish a dependency. I had assumed
> > > that
> > > this what you had done when you said you had created a cells-aware
> > > store.
> > >
> >
> >
> > And you were assuming right -- That is, I hope what I did is what you
> > mean.  Indeed bwen-(c-)gethash (which I will rename to
> > bwhen-in-c-store or sth like that) expands into some code that creates
> > a dependency on a listener object in the store, which then in turn is
> > kicked when the hash table is updated.
> >
> >
> >  I
> > > was guessing that behind the scenes there was a second hashtable with
> > > the
> > > same key but a value that was a list of the cells that had looked it
> > > up. (Or
> > > you could try stuffing the thing stored with a list of asking cells in
> > > the
> > > one hash-value.)
> > >
> >
> >
> > Indeed there are two hash tables, one with the actual stored stuff and
> > one with auxiliary objects that are uses to toggle the update.  This
> > way we have two hash table lookups for every access, so maybe it would
> > make sense to keep the two in a cons in one table.  But hold on, I
> > hear "premature optimization".
> >
>
> I was not thinking about efficiency, I was thinking about (possibly!)
> cleaner design less likely to be midcoded: I want to get all the information
> about this hash key as a single logically related chunk, not pull in the
> properties of the logical chunk one at a time from different hash tables per
> property. Then I can pass this chunk around to other functions as one
> parameter, for example. But that is beside the point.
>
>
> >
> >  That would have gotten you into c-link, c-unlink, and other
> > > good stuff.
> > >
> >
> >
> > Not sure whether we are on the same page.  I have register-listener,
> > kick-listener, and unregister-listener as internal methods on the
> > store.  I assume we're talking similar ideas here.  I like your naming
> > convention, tho.
> >
>
> <g> We might be on the same page talking different languages and that is
> the problem: cells get optimized away when they are "unlinked" to a
> dependency. You created dependency links in another language if you will and
> something got lost in translation (great movie).


The "other language" was that of "registered listener", which of course
c-optimize-way knows not about.


>
>
> Can you re-implement such that the linking API Just Works(tm)?


Here I left unstated my preference for re-engineering around link/unlink and
the alternative of telling c-optimize-away about an alternative way of
encoding inter-cell dependency. That preference will change rapidly if there
is some way c-link/unlink will not work for a hashtable-based namespace.

kt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/cells-devel/attachments/20080421/f51dc893/attachment.html>