Responses to your comments
Panu Kalliokoski
(03 May 2005 20:51 UTC)
|
Re: Responses to your comments
bear
(05 May 2005 08:27 UTC)
|
Re: Responses to your comments
Scott G. Miller
(05 May 2005 12:32 UTC)
|
Re: Responses to your comments Panu Kalliokoski (06 May 2005 08:44 UTC)
|
Re: Responses to your comments
Sven.Hartrumpf@xxxxxx
(04 Aug 2005 14:22 UTC)
|
Re: Responses to your comments
Panu
(05 Aug 2005 06:57 UTC)
|
Re: Responses to your comments Panu Kalliokoski 06 May 2005 08:40 UTC
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/