[cells-devel] Optimized away/dying rules

[Ken Tilton]

Oh christ....

On Mon, Apr 21, 2008 at 8:44 PM, Ken Tilton <kentilton at gmail.com> wrote:

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

/over/ the alternative!!!!!!!!!!!!!!!!!!

:)

kt


> 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/3847e4bd/attachment.html>