Guile Mailing List Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Scheme style auto-resizing hashtable (fwd)
hjstein@bfr.co.il writes:
> Rob Browning <rlb@cs.utexas.edu> writes:
>
> > Note that their justification for each() makes sense (at least given
> > that perl can tie() hashes to DBM files):
> >
> > Note that functions such as keys() and values()
> > may return huge array values when used on large
> > DBM files. You may prefer to use the each()
> > function to iterate over large DBM files.
> > Example:
> >
> > # print out history file offsets
> > dbmopen(%HIST,'/usr/lib/news/history',0666);
> > while (($key,$val) = each %HIST) {
> > print $key, ' = ', unpack('L',$val), "\n";
> > }
> > dbmclose(%HIST);
>
> Handled by hashtable-for-each.
>
Upon further consideration of this and other messages, I think the
best solution is to provide hashtable-for-each and hashtable-map
(which would map to a list, not a hashtable); the former can be used
when you want to avoid any superfluous consing at all and the latter
if you want to collect the resulting values. hashtable->alist and
hashtable->keys can trivially be written in terms of hashtable-map
(but could be provided in C if that notably improves efficiency, since
they are likely to be common idioms).
C++-style iterators can be simulated using hashtable-for-each and
call/cc, but I still think they suck. Mappers lead to shorter, more
readable code than iteration constructs, this was true even when the
languages in question were APL vs. PL/1 rather than Lisp vs C++/Java.
I think in general it is more convenient to pass code to an iteration
or mapping or filter than vice versa, you just can't do this very well
in C++ or Java because they don't have proper closures. You could make
a closure-like class perhaps, but it would be a pain. Now, if you
could overload operator() in C++ (and therefore define callable
classes) maybe you could have some fun.
- Maciej
Guile Home |
Main Index |
Thread Index