On Mon, May 27, 2013 at 12:37 PM, Alexey Radul <[email protected]> wrote: > On Sun, May 26, 2013 at 9:29 PM, Alex Shinn <[email protected]> wrote: > > I also think the following utility is nice, as there is no other > > existing utility to use a hash-table as a cache with a single > > operation: > > > > (hash-table-ref/cache! table key thunk) > > => (hash-table-search > > table key > > (lambda (value update remove) > > value) > > (lambda (insert) > > (let ((res (thunk))) > > (insert res) > > res))) > > I got in trouble with this one once because the thunk was a call to a > recursive function, and the hash table was that function's memoization > cache. So calling the thunk caused many entries to be added to the > table, which caused the table to resize itself, which made the > precomputed bucket inside the insert procedure I had invalid, which > made me sad. That problem can of course be fixed in a careful > implementation (insert can check some serial number or dirtiness bit > and fall back to recomputing the hash), but getting this to be both > clean and efficient is nontrivial. I wonder what language, if any, > the proposal should include warning either users to avoid or > implementers to solve this problem. >
Good point. Note this problem is inherent in hash-table-search, not specific to hash-table-ref/cache! (or whatever it should be called). The language can simply say that the `update', `remove' and `insert' thunks must remain valid for their lifetimes. -- Alex
_______________________________________________ Scheme-reports mailing list [email protected] http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
