[cells-devel] Optimized away/dying rules

[Ken Tilton]

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

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


kt