Am Di., 16. März 2021 um 14:43 Uhr schrieb Alex Shinn <xxxxxx@gmail.com>:
On Tue, Mar 16, 2021 at 4:52 PM Marc Nieper-Wißkirchen
<xxxxxx@nieper-wisskirchen.de> wrote:
>
> Am Di., 16. März 2021 um 08:24 Uhr schrieb Daphne Preston-Kendal <xxxxxx@nonceword.org>:
>>
>> They do — the ‘less?’ argument. These procedures can also be used with comparators in the SRFI 128 sense quite easily: just pass the comparator-ordering-predicate of the comparator as the ‘less?’ argument.
>
>
> The general philosophy seems to have been lately not to use bare ordering predicates in public APIs but to always accept comparators.

I think that only makes sense for those few APIs where either an
ordering or hash could be applicable.
Otherwise it's extra complexity and boilerplate to wrap a custom
`less?' in a dummy comparator.

John may be able to say more about his philosophy regarding comparator objects.

While an API taking comparator objects instead of a raw comparator procedure adds one more layer, it also has a number of advantages:

(a) The API itself will be more typesafe because comparator objects form a disjoint type whereas procedures can mean anything.
(b) A comparator object includes a type test, which can be used in conjunction with `assert` or `assume` in the implementation.
(c) A later extension of SRFI 223 may add procedures where also equality of values has to be tested, and comparator objects already package an equality predicate.
(d) It is always good (for documentation and clarity) that a comparator object is defined for any user data-type whose values are to or can be searched against. So a suitable comparator object should already be lying around.