[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Walking Hash Tables
- To: srt@UCLA-LOCUS
- Subject: Walking Hash Tables
- From: Jonathan A Rees <JAR@MIT-MC>
- Date: Thu ,11 Apr 85 19:29:55 EDT
- Cc: T-DISCUSSION@MIT-MC
- In-reply-to: Msg of Wed 10 Apr 85 17:31:01 PST from Scott Turner <srt at UCLA-LOCUS>
Date: Wed, 10 Apr 85 17:31:01 PST
From: Scott Turner <srt at UCLA-LOCUS>
Is there a way to walk a hash table in T2.8? Is there a way to
specify a predicate other than EQ?. Will these things be added to
T2.9?
["T-Users" is intended to be a one-way channel from implementors to
users, or for announcements of general interest; "T-Discussion" is for
discussion. Since nobody seems to respect this intent, however (I can
understand why, since the names are not mnemonic), the distinction might
be flushed sometime in the future, or else the list that is now
"T-Users" will be renamed "T-Announcements", and "T-Users" will become a
synonym for "T-Announcements".]
Answers: internally in the implementation, but not released; no; and no.
You should check for (I think) TABLE-WALK in the implementation
environment; look at the source.
I didn't think it was a good idea to make "walking" part of the table
abstraction, since: (a) it isn't necessary (it can be simulated); (b) it
complicates the implementation & specification (there's too much lard in
the manual already); and (c) it is potentially pre-emptive of the
possibility of one day making tables be "weak," in the sense that an
entry goes away if its key becomes inaccessible. Yes, it would be
possible to lock out GC's, make an internal list of the objects which
are keys, unlock GC's, and then apply the procedure to those keys, but
that seems like a lot of trouble for something that isn't even very
well-formed (how do you axiomatize "accessible"?).
To simulate WALK-TABLE, just keep, along with the table, a list of all
the keys. I guess the disadvantage of this is that deletion can be
expensive; I'll think about it.
Jonathan