Some comments on SRFI 128 Draft #5 (2015/11/08):

  * Would it be desirable to relax the restrictions noted under
    Limitations for comparators created using programmer-defined
    type-tests, equality and ordering predicates, and hash function?

  * Are comparators that reflect a partial ordering of objects
    permitted?  The definition of ordering predicate seems to permit it.
    In particular, is it permitted for a comparator to have an ordering
    predicate that always returns false (regardless of anything else)?
    A clarification either way would be useful.  (I may have just missed
    it, or I may just be misreading the mention of total order in the
    Definitions section.)

  * hash function definition: Even though using it is optional, what
    is the expected interpretation of the second argument as upper
    bound: inclusive or exclusive?  I would guess the latter based on
    common convention, but a clarification would be helpful.

  * comparator-register-default!: What is the behavior if this
    procedure is used to register two comparators, both of whose type
    test predicates return true for some objects?

  * (minor) The Abstract and Rationale refer to "equality procedure"
    and "ordering predicate", which seems to suggest a subtle
    difference.  However, I believe both procedures are predicates, so
    a parallel wording may be clearer.

  * (very minor) Beginning of Specification: I don't understand the
    significance of the choice of the (comparators) library name
    instead of (srfi 128), beyond what is stated there.  (I realize
    this may change when the sample implementation is added/updated.)

  * (minor) Top of the Constructors section: "type test predicates"
    may be preferable to "type test functions".

  * (minor/confirmation) In general, when the SRFI says "hashes them
    together" in the context of hashing a composite value from the
    hashes of its constituents (e.g., in the description of
    make-list-comparator), is it correct that there is no requirement
    on the hash function of the composite value other than it being a
    function of those constituent hashes?  In particular, is it true
    that a horrible hash function that always returns 0 is always
    technically correct?

  * (minor) make-equal-comparator: The portion after the semicolon in
    the fourth item seems to be a repetition of the first item.

Regards,

-chaw