Oh christ....
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!!!!!!!!!!!!!!!!!!
:)
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