On Thu, May 05, 2005 at 07:31:57AM -0500, Scott G. Miller wrote:
> request was that the naming and functionality match SRFI-44, not that
> this SRFI provide an implementation which portable works with SRFI-44.
>  You're right the latter isn't possible (which I don't see as a
> problem, since users don't create the implementations).  But matching
> the interface keeps datastructures consistent and makes it simpler for
> implementors to bind into their SRFI-44 collection sets.

Boys, don't fight :)

I think I understood your point right.  Now, to elaborate on the
problems I see here:

(1) the equivalence function is not sufficient for hash tables that use
coarser equivalence than equal?.  This presents a problem for the
interface of the basic constructor.

(2) the design decision of equating items of sets and bags with _values_
of maps, not keys, leads to an ugly interface where maps have an
equivalence predicate for values even though they certainly do not need
one.  As a result, I'd like to collapse these two.

(3) to support SRFI-44, I should rename -keys into -keys->list, -values
into ->list, and -exists? into -contains-key?  I find this ugly, though
doable if some people second it.  (The names are consistent but somewhat
too long and somewhat contrary to "traditional" view of hash tables.)
But I'd rather see these as glue between SRFI-69 and SRFI-44, not
something that should be incorporated in SRFI-69 directly.

(4) I might add (hash-table ...) as suggested by SRFI-44.  Too bad that
it has the wart of value equivalence functions.  Also,
hash-table-comparison-function is likely to be renamed into
hash-table-equivalence-function for avoiding confusion with SRFI-67.

(5) I might add -add-from, though I think it should be named -merge.

Overall, I think the problem is that mappings are collections in some
ways, and in others, they are not.  One can view them as collections of
(key,value) pairs, or as collections of values, which just happen to be
associated with some keys.  One can also view them as collections of
keys, which happen to have additional information about values.  The
first view makes them consistent with all collections, but with a
restricted value type, unlike all other collections.  The second view
(apparently adopted by SRFI-44) makes them consistent with lists and
vectors, but inconsistent with sets, search trees and the like.  The
third view would arguably be the cleanest one...

Panu

--
personal contact: xxxxxx@iki.fi, +35841 5323835, +3589 85619369
work contact: xxxxxx@ling.helsinki.fi, +35850 3678003
kotisivu (henkkoht):	http://www.iki.fi/atehwa/
homepage (technical):	http://sange.fi/~atehwa/