That was fuzzy. Clarifications below... On Mon, Apr 21, 2008 at 8:31 PM, Ken Tilton <[EMAIL PROTECTED]> 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
_______________________________________________ cells-devel site list cells-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/cells-devel
