Comments on SRFI 128 Draft 5 (2015-11-08). Sudarshan S Chawathe 09 Nov 2015 16:34 UTC
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