Sudarshan S Chawathe scripsit:

> I found SRFI 128 interesting.  Here are some minor comments based on a
> quick reading of Draft #1 (2015/10/26).  Caveat: I have not caught up
> with the discussion of SRFI 114, which is obviously relevant.

The intention is that SRFI 128 should be clear without reference to
SRFI 114, so that it can replace it.

>   * There is a partial sentence at the end of the second paragraph of
>     the Rationale section.

Fixed.

>   * There is an extra "p>" at the beginning of the Specification
>     section.

Fixed.

>   * For the comparator returned by make-pair-comparator: It is
>     probably obvious, but is it correct that the returned comparator
>     implements equality as conjunction of car and cdr equality predicates,

Yes, that's correct (and implied, I think).

>     and similarly for the type-test?

This is a genuine issue that hasn't been raised.  Historically the type
test for a container data type has looked only at the container: thus,
it verifies that a vector is a vector, not that it is (for example)
a vector containing numbers.  If it did the latter, the type test
would imply recursing all the way down.

I'll add this to the issues: it applies equally to list-comparator and
vector-comparator.

>   * I believe that the text uses "result of that comparison" (e.g., in
>     the description o make-list-comparator) to denote the result of the
>     ordering predicate.  If true, using "result of the ordering predicate"
>     may be clearer.
>
>   * An observation similar to the above also applies to
>     make-vector-comparator.

I use "comparison" to refer to both the equality and the ordering predicate,
which must be consistent and must represent a total order.

>   * Missing space in "functinonumber-hash" (7th item in
>     make-default-comparator's description).

Fixed.

>   * In the "Comparison predicates" section: I think the intent is
>     clear, but the description does not explicitly refer to the equality
>     and ordering predicates of 'comparator' and uses 'comparison
>     procedure' instead.

Left over from SRFI 114.  Fixed.

>   * Earlier (in Constructors), is the note "..., since comparators are
>     pure and functional".  Is it true that the bundled procedures are
>     therefore explicitly prohibited from causing side effects?  A more
>     explicit statement either way would be useful.

I did not intend that, but it's a good idea.  Added.

--
John Cowan          http://www.ccil.org/~cowan        xxxxxx@ccil.org
So they play that [tune] on their fascist banjos, eh?
        --Great-Souled Sam