This page is part of the web mail archives of SRFI 69 from before July 7th, 2015. The new archives for SRFI 69 contain all messages, not just those from before July 7th, 2015.
On 4/26/05, bear <bear@xxxxxxxxx> wrote: > > > On Mon, 25 Apr 2005, Scott G. Miller wrote: > > >First, its definitely a good thing to see hashtables get SRFI > >treatment. It would be a shame though if they weren't defined as > >compatible with SRFI-44, whose purpose is to unify datastructures so > >that they can be used generically and consistently in programs. > > I think srfi-44 fails to do that. It doesn't provide > any infrastructure with a way for collection code to > "register" itself so as to be usable via generic functions, > so there is absolutely no "pluggable interface" in a code > sense. Thats an implementation concern. The "generic and consistent" refers to the experience of the programmer, not the implementor. > > >This basically only entails a little effort in procedure naming, and > >in providing compatible fold functions. It would be nice to say also > >that implementations that support SRFI-44 must support the hashtables > >for the generic elements of SRFI-44. > > Further, folding enumerators aren't particularly meaningful > operations on hash tables, because hash tables lack a concept > of ordering. I don't think that hash tables *ought* to > provide them, because they will encourage naive users to do > horribly inefficient things. Why? Most naive users won't go near fold anyway if thats your concern. But its certainly useful for programmers to be able to add the bindings of one map of unknown origin to the hashtables of this SRFI. Scott > > Bear > >