This is the mail archive of the guile@cygnus.com mailing list for the guile project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
jglascoe@jay.giss.nasa.gov writes: > and another thing, > > I'm going to completely re-haul make-hashtab to accept one optional > argument: either an alist or a vector of associations. I figure my hash > tables do an excellent job of choosing (and modifying) max-bucket-size, > and they resize so quickly that an initial number-buckets of 4 is more > than adequate. As for the auto-shrink argument, well the user will just > have to call hashtab-(en|dis)able themselves. > > 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'd suggest providing alist->hashtab (and hashtab->alist or at least hashtab-keys) instead of overloading the constructor. I'm not sure association vectors are very useful - they don't offer either performance or flexibility, though I suppose they are about easy to iterate on as alists. - Maciej