Guile Mailing List Archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Scheme style auto-resizing hashtable (fwd)




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.

Iterators are very un-Schemely, IMO, Scheme is not in the business of
telling you how to iterate. I thought a bit about this, and while
hash->alist might be nice, hash->keys could be more memory and time
efficient, and would have the advantage of letting you filter the key
list before accessing the values you care about. It would be easy to
write either of hash->keys and hash->alist in terms of the other, but
it seems more logical to have has->keys be the primitive.

 - Maciej



Guile Home | Main Index | Thread Index