Some remarks on the implementation Jakob Wuhrer (26 Feb 2022 19:16 UTC)
Re: Some remarks on the implementation Jakob Wuhrer (27 Feb 2022 08:26 UTC)

Some remarks on the implementation Jakob Wuhrer 26 Feb 2022 15:33 UTC
Hi Daphne,

thanks for this great SRFI!

As may be apparent based on the subject of this mail, I have a few
suggestions/comments

First of all, I believe that there is a small bug in the procedures
`make-product-comparator` and `make-sum-comparator` with regards to how
these deal with comparators that are not ordered / not hashable.

I think that in [1] on lines 35, 43, 74, and 84, the occurences of
comparator-ordering-predicate and comparator-hash-function ought to be
replaced by comparator-ordered? and comparator-hashable?, respectively.

The srfi-128 document seems to imply that comparator-ordering-predicate
or comparator-hash-function always return a truthy value - If the
comparator is unordered/unhashable, this value will be a function that
raises an error when called, otherwise, it'll be the sorting predicate /
hash function that was provided to make-comparator.

Second (and of significantly lesser importance): have you considered
implementing make-product-comparator and make-sum-comparator in terms of
fold? While that would probably incur some performance losses, I think
it'd make the code more easy to understand.

Third (and finally): Would a make-reversed-comparator function "fit" in
with this SRFI?

I've attached a file containing some rough, untested implementations of
the functions described in my second and third remarks.

Kind regards,
Jakob Wuhrer

[1]: https://github.com/scheme-requests-for-implementation/srfi-228/blob/798d4f4ce8795498b1e2f556d35c2be405085d42/composing-comparators.scm#L35