On reflection, I agree that they should be disjoint.  Perhaps it would be good to remove (srfi 142 hash) from the SRFI altogether, and leave it to another SRFI.  My (incomplete) implementation doesn't depend in any way on yours, so I would be fine with that, and the SRFI could be very short, just listing the procedures and saying they are semantically equivalent to their SRFI 142 counterparts.  In that case I would want the procedures to have different names, hashmapping-* or what not.

So then it is agreed upon that I am adding a sentence saying the mapping types exported by (srfi 146) and (srfi 146 hash), respectively, are disjoint.

I have decided, however, to leave the specification of (srfi 146 hash) in the spec. The rationale for this is threefold:

1) It is easy to prefix the procedures in (srfi 146 hash) by hand by using the prefix import modifier of the R7RS library system.
2) I see (srfi 146) as a fallback for those implementations that do not provide (srfi 146 hash). If they are in different SRFIs, the existing of such a fallback is not guaranteed. As things are now, user code that wants to handle mappings of objects with no natural order can try (srfi 146 hash) first before having to fallback to (srfi 146) with an adhoch ordering.
3) Most of the functionality provided by (srfi 146 hash) is already in (srfi 125), hash tables. So if we were about to create a new SRFI that is concerned with mappings based on hashing, it should be some kind of unification of (srfi 125) and (srfi 146 hash).

--

Marc
 

-- 
John Cowan          http://vrici.lojban.org/~cowan        xxxxxx@ccil.org
There is no real going back.  Though I may come to the Shire, it will
not seem the same; for I shall not be the same.  I am wounded with
knife, sting, and tooth, and a long burden.  Where shall I find rest?
                --Frodo



To unsubscribe from this list please go to http://www.simplelists.com/confirm.php?u=oa8YQq670QJsajDJIblEsMJ9MoezHUAm