If I'm only interested in the side-effects of a call to REMHASH (i.e., 'removing' a hash table entry) then is
(remhash key hash-table)
functionally equivalent to
(setf (gethash key hash-table) nil) ?
I guess I'm really asking if in a 'typical' implementation REMHASH removes entries by overwriting their place in the hash-table with NIL.
--
*
Len Charest, Jr. ·······@ai-cyclops.jpl.nasa.gov
JPL Artificial Intelligence Group
*
In article <······················@jpl-devvax.jpl.nasa.gov> ·······@AI-Cyclops.JPL.NASA.GOV writes:
>If I'm only interested in the side-effects of a call to REMHASH (i.e., 'removing' a hash table entry) then is
> (remhash key hash-table)
>functionally equivalent to
> (setf (gethash key hash-table) nil) ?
>
I would expect them to be different.
(progn (remhash key hash-table) (gethash key hash-table "default"))
should return "default" but
(progn (setf (gethash key hash-table) nil) (gethash key hash-table "default"))
should return nil.
Andreas Girgensohn
········@cs.colorado.edu
In article <······················@jpl-devvax.jpl.nasa.gov> ·······@AI-Cyclops.JPL.NASA.GOV writes:
>If I'm only interested in the side-effects of a call to REMHASH (i.e.,
>'removing' a hash table entry) then is
> (remhash key hash-table)
>functionally equivalent to
> (setf (gethash key hash-table) nil) ?
>I guess I'm really asking if in a 'typical' implementation REMHASH removes
>entries by overwriting their place in the hash-table with NIL.
No, because there are several ways to distinguish a nonexistent hash table
entry with one whose value is NIL. GETHASH takes an optional "default"
argument, which is the value to return if the key isn't found. GETHASH
also returns a second value, which is NIL if and only if the key wasn't
found.
In implementations where hash buckets are implemented as lists, I expect
REMHASH removes the entry from the list. In implementations where all the
elements are in a big array (e.g. linear hashing), they presumably have a
flag in the entry that indicates whether it is in use (this is also
generally necessary to know when to stop searching).
I suggest you read any good reference on hashing techniques (e.g. Knuth); I
expect that most Lisp hash table implementations use something you'll see
there (some may use more than one -- the Symbolics table facility changes
the representation as the table grows, choosing the optimal algorithm for
the current size).
--
Barry Margolin, Thinking Machines Corp.
······@think.com
{uunet,harvard}!think!barmar