Oh christ....<br><br><div class="gmail_quote">On Mon, Apr 21, 2008 at 8:44 PM, Ken Tilton <<a href="mailto:kentilton@gmail.com">kentilton@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
That was fuzzy. Clarifications below...<div><br><br><div class="gmail_quote"><div><div></div><div class="Wj3C7c">On Mon, Apr 21, 2008 at 8:31 PM, Ken Tilton <<a href="mailto:kennytilton@optonline.net" target="_blank">kennytilton@optonline.net</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div></div><div>Peter Hildebrandt wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8x;border-left:1px #ccc solid;padding-left:1ex">
Ken,<br>
<br>
thanks again for the info.  I guess some stuff got out of order here:<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8x;border-left:1px #ccc solid;padding-left:1ex">
First, just a point of information: do I understand correctly that the<br>
original example below uses an assoc instead of your store just to simplify<br>
the problem and highlight the key issue?<br>
</blockquote>
<br>
<br>
Yes and no.  Yes, the list stuff was my attempt of singling out what<br>
was going on.  But! -- I wrote the stuff *before* I understood the<br>
issue; in other words, this is how I tried (!) to do it before I made<br>
the cells store.<br>
<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8x;border-left:1px #ccc solid;padding-left:1ex">
I am guessing yes, so I will charge ahead with my thoughts: basically you<br>
need to make the lookup itself establish a dependency. I had assumed that<br>
this what you had done when you said you had created a cells-aware store.<br>
</blockquote>
<br>
<br>
And you were assuming right -- That is, I hope what I did is what you<br>
mean.  Indeed bwen-(c-)gethash (which I will rename to<br>
bwhen-in-c-store or sth like that) expands into some code that creates<br>
a dependency on a listener object in the store, which then in turn is<br>
kicked when the hash table is updated.<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8x;border-left:1px #ccc solid;padding-left:1ex">
I<br>
was guessing that behind the scenes there was a second hashtable with the<br>
same key but a value that was a list of the cells that had looked it up. (Or<br>
you could try stuffing the thing stored with a list of asking cells in the<br>
one hash-value.)<br>
</blockquote>
<br>
<br>
Indeed there are two hash tables, one with the actual stored stuff and<br>
one with auxiliary objects that are uses to toggle the update.  This<br>
way we have two hash table lookups for every access, so maybe it would<br>
make sense to keep the two in a cons in one table.  But hold on, I<br>
hear "premature optimization".<br>
</blockquote>
<br></div></div>
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.<div>

<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8x;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8x;border-left:1px #ccc solid;padding-left:1ex">
That would have gotten you into c-link, c-unlink, and other<br>
good stuff.<br>
</blockquote>
<br>
<br>
Not sure whether we are on the same page.  I have register-listener,<br>
kick-listener, and unregister-listener as internal methods on the<br>
store.  I assume we're talking similar ideas here.  I like your naming<br>
convention, tho.<br>
</blockquote>
<br></div>
<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).</blockquote>

<div><br></div></div></div><div>The "other language" was that of "registered listener", which of course c-optimize-way knows not about.</div><div class="Ih2E3d"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
<br>
Can you re-implement such that the linking API Just Works(tm)?</blockquote><div><br></div></div><div>Here I left unstated my preference for re-engineering around link/unlink and the alternative of telling c-optimize-</div>
</div></div></blockquote><div><br></div><div>/over/ the alternative!!!!!!!!!!!!!!!!!!</div><div><br></div><div>:)</div><div><br></div><div>kt</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div class="gmail_quote"><div>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.</div>

<div><br></div><div>kt</div><div><br></div></div></div>
</blockquote></div><br>