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 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: atehwa@xxxxxx, +35841 5323835, +3589 85619369 work contact: pkalliok@xxxxxxxxxxxxxxxx, +35850 3678003 kotisivu (henkkoht): http://www.iki.fi/atehwa/ homepage (technical): http://sange.fi/~atehwa/