[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: John Rose <firstname.lastname@example.org>, email@example.com
- From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
- Date: Fri, 23 Sep 88 12:36:11 BST
- Cc: jonl <@sail.stanford.edu:firstname.lastname@example.org>, Moon@scrc-stony-brook.arpa, email@example.com, SEB1525 <@NSS.Cs.Ucl.AC.UK,@sail.standfor.edu:SEB1525@draper.com>
> As long as we're still talking about weak pointers and related topics,
> I should note that there seem to be two very different broad categories
> of weak pointer usage. (If you know a third, please speak up.)
> 1. Hash Consing
> This kind of usage has been mentioned on this mailing list already.
> The idea is that you need to add a slot to an object, but you don't
> have control over the object's memory layout.
> 2. Back Pointers
> One thing that would help here is a "weak set" construct,
> You can build a weak set out of a (:TEMPORARY T :TEST 'EQ) hash
> table by storing the back pointers as keys. The values stored
> on the keys are immaterial; T would do fine!
I did mention this in one of the earlier messages because I wanted
T's weak sets to count as part of "current practice". Since
an implementation using hash tables does waste 1/2 of each entry,
you're type suggestion seems reasonable. (Quick look at arrays
in CLtL...) Indeed, array element types are also specified by a
keyword parameter so there is precedent for that approach.
There should probably be a type parameter for the key as well.
So we'd have :KEY-TYPE and :VALUE-TYPE.