Re: Scheme style auto-resizing hashtable (fwd)

[hjstein@bfr.co.il (Harvey J. Stein)]

Rob Browning <rlb@cs.utexas.edu> writes:

 > Jay Glascoe <jglascoe@jay.giss.nasa.gov> writes:
 > 
 > > Now, why the optional alist/vector of associations argument?  I
 > > figure that someone using an alist that grows larger than they
 > > expected (say >100) can easily trade it in for a hash table.  And
 > > any good avl-tree will probably have avl->alist and avl->vector
 > > procedures.
 > 
 > I think it's been mentioned, but some way to get a list of the keys
 > would be quite helpful, perhaps a hash->keys, hash->alist, or even a
 > make-hash-iterator function.
 > 
 > There are times when I need to iterate over all the elements of a hash
 > table (after some long processing step), and with the current code I
 > can't see a (clean) way to do it.  Of these three approaches, the
 > iterator approach would be more memory efficient, but probably a mess
 > otherwise.
 > 
 > The iterator approach would be more memory efficient, but probably a
 > mess otherwise.

STk also has a hastable-map (or is it hashtable-foreach), but I don't
like the order of the arguments - it takes the hashtable & then the
fcn (like the other hashtable fcns), whereas I'd prefer the fcn & then
the hashtable (like the other mapping fcns).  Obviously there're pros
& cons for each.

I guess you don't want a hashtable-map because the order of the
elements is somewhat meaningless.  Maybe just a hashtable-foreach
would be appropriate.

-- 
Harvey J. Stein
BFM Financial Research
hjstein@bfr.co.il