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.
> >SRFI-44 compatibility: > > I looked at the applicable parts of SRFI-44 (map API) and didn't > > like it. However, if an implementation should want to give a > > SRFI-44 interface to SRFI-69 hash tables, it is easy enough to > > do so. The way of doing so is sufficiently defined in SRFI-44, > > so I won't bother with that. > > This is laughable btw; the reason it was an absurd request > in the first place is precisely because srfi-44 leaves this > very thing (how to add methods to its overloaded functions) > unspecified. There is no such thing as a portable interface > to SRFI-44, so you were quite right to ignore the request for > one. I'm laughing at you now, since you just don't seem to get it. My 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. Scott