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

That was fuzzy. Clarifications below...

On Mon, Apr 21, 2008 at 8:31 PM, Ken Tilton <kennytilton@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!!!!!!!!!!!!!!!!!!

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