> >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