Thanks, John.

Am 20.07.2017 um 04:20 schrieb John Cowan:
> The index has mapping-comparator but not make-mapping-comparator.

Fixed.

> The body text makes comparator? an exported identifier, but I see no
> reason why it should be exported.  If you want it, import (srfi 128).

It is not harmful either. But it helps to detect if an implementation of
the R7RS library is broken in the sense that it does not allow
interdependent libraries. If a program imports as follows (import (srfi
128) (srfi 146)), it would be an error (detectable at expansion time) if
the Scheme system loaded (srfi 128) twice, once for importing into the
program, and once for importing into (srfi 146). Namely, in that case
the main program would import comparator? with two different bindings.

If (srfi 146) didn't export comparator?, multiple loadings of (srfi 128)
would not be detected early; only when a (srfi 146) procedure is
executed with a comparator defined in the main program and coming from
the other loading of (srfi 128).

See this post of mine:
https://groups.google.com/d/msg/scheme-reports-wg2/NZA9CIMRl48/CJ4Xn27CAwAJ.
And the preceding and following discussion.

(One may view exporting comparator? as a hack only necessary because the
R7RS library system omits to say anything about interdependent library
(which we use everywhere when implementing SRFIs for R7RS-large); one
can, however, also make independently sense out of it: By exporting
comparator?, (srfi 146) declares or announces what the type is, its
procedures depend on.)

> In the definition of mapping-pop, for "an arbitrary (but see below)
> association" read "the association with the least key".  The second
> paragraph should read "The hashmap-pop procedure returns an arbitrary
> association."
>
> In the definition of mapping-search, for "is searched" read "is
> searched in the order of the stored keys".  Change the second
> paragraph to "The hashmap-search procedure searches in arbitrary order."
>
> In the definition of mapping-find, for "arbitrarily chosen
> association" read "the association with the least key".  Change the
> second paragraph to "The hashmap-find procedure searches in arbitrary
> order."
>
> In the definition of mapping-keys, for "all the keys" read "all the
> keys in increasing order".  Change the second paragraph to "The
> hashmap-keys procedure returns the keys in arbitrary order."
>
> In the definition of mapping-values, for "all the values" read "all
> the values in increasing order of the keys".  Change the second
> paragraph to "The hashmap-keys procedure returns the values in
> arbitrary order."
>
> In the definition of mapping-entries for "The two lists" read "in
> increasing order of the keys.  The hashmap-entries procedure returns
> the two lists".  Drop the second paragraph.
>
> In the definitions of mapping-map, mapping-for-each, mapping-fold: for
> "in arbitrary order (but see below)" read "in increasing order of the
> keys".  Change the last paragraph to "The <whichever> procedure
> processes the associations in arbitrary order."
>
> In the definition of mapping-map->list, for "for every association"
> read "for every association in increasing order of the keys".  Change
> the second paragraph to "The hashmap-map->list procedure processes the
> associations in arbitrary order."
>
> In the definition of mapping->alist, for "in unspecified order" read
> "in increasing order of the keys".  Change the second paragraph to
> "The hashmap->alist procedure processes the associations in arbitrary
> order."
> In the definitions of mapping/ordered and mapping-unfold/ordered, the
> words "if they are imported from (srfi 146)" are now superfluous.  It
> is still an error to create a hashmap from unordered input in this
> function, though the error will probably not be caught.

This seems to be a meta-issue. In the paragraph preceding the index, it
says (in HTML):

"<p>To make it possible for a program to easily import <code>(srfi
  146)</code> and <code>(srfi 146 hash)</code> at the same time, the
  prefix <code>mapping</code> that prefixes the identifiers
  in <code>(srfi 146)</code> is substituted by <code>hashmap</code>
  in <code>(srfi 146 hash)</code>.  For example, <code>mapping</code>
  becomes <code>hashmap</code>, <code>mapping?</code>
  becomes <code>hashmap?</code>, and <code>mapping-ref</code>
  becomes <code>hashmap-ref</code>.
  <code>comparator?</code> remains unchanged.
  For simplicity, the rest of this
  SRFI refers to the identifiers by their names in <code>(srfi 146)</code>.
</p>"

This is why you won't find the prefix "hashmap-" anywhere else. I wanted
to keep the question of naming/prefixing the procedures independently to
the semantical descriptions of what the procedures do. So in some sense,
the identifiers defined are "meta-identifiers", standing either for the
corresponding identifier as exported from (srfi 146) or as exported from
(srfi 146 hash).

I think, at least logically, the SRFI says exactly what you want it to say.

If not, please reply.

Marc