Date: Sun, 20 Dec 2009 00:43:25 -0800 From: Joe Marshall <[email protected]>
On Sun, Dec 20, 2009 at 12:25 AM, Taylor R Campbell <[email protected]> wrote: > I don't buy `they shouldn't' unless we're prepared to eliminate > HASH-TABLE/KEY-LIST, HASH-TABLE/DATUM-LIST, HASH-TABLE/FOR-EACH, &c., > and then rewrite everything that uses them to use a different > abstraction. I don't think so. If a hash table is a mapping from key to value, then the key list need only contain those items that could conceivably be looked up. It *doesn't* need to contain keys that cannot appear as arguments to hash-table/get (a subtle difference) There is indeed a subtle difference here, but it is one that the hash table abstraction should present clearly as a choice to the user. The hash table abstraction does provide this choice, but I contend that the name MAKE-EQ-HASH-TABLE inadequately, and dangerously, conveys the option its current implementation implies in this choice. The only reason that this may not have bitten anyone before is that nobody has implemented any weak internment scheme for objects that are ever used as keys in eq hash tables -- and the other cases are highly unlikely to be encountered. For example, the threading algorithm in edwin/nntp.scm will break, I believe, if the garbage collector runs some time between the evaluation of the last FOR-EACH call and the evalution of the last MAP call in BUILD-EQUIVALENCE-CLASSES. That's highly unlikely to happen, though, especially since very few people use Edwin's newsreader, and those who do only very infrequently call BUILD-EQUIVALENCE-CLASSES. _______________________________________________ MIT-Scheme-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/mit-scheme-devel
