On 16 Mar 2021, at 15:41, Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:

> Am Di., 16. März 2021 um 14:43 Uhr schrieb Alex Shinn <xxxxxx@gmail.com>:
> [snip]
>> 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.

I have spoken to John about this, and he essentially agrees with Alex's statement. Since the *only* thing this SRFI needs is the comparator-ordering-predicate, a full SRFI 128 comparator isn’t needed.

That said …

> 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.

The third draft will tighten up the language to make clear that it’s the programmer’s responsibility to provide a ‘less?’ predicate which gives a total ordering of its two arguments, and which can handle ordering for all of the items in the sequence. I know this doesn’t really *resolve* these two issues, but it does make them explicit in the documentation, which is the next best thing.

> (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.

This is my real concern, and to some extent from this perspective I can sympathize with Daniel Itaboraí’s complaint that the procedures here so far are too low-level. While they provide the exact same functionality that comes bundled in the corresponding Python module, inasmuch as it makes sense in a Scheme context (see my response in the relevant thread to his request for ‘insort’ procedures), the manual page for that Python module (https://docs.python.org/3.9/library/bisect.html) also admits that they’re low-level and provides recipes for functions called index and find_{lt,le,gt,ge}.

I can see an argument for providing the procedures which Python punts out to the manual page as built-in to this SRFI (especially index), using comparators instead of comparison predicates — but they’d have to be defined again for every sequence type, and with the intended generalized nature of this SRFI, I can’t immediately think of an elegant way to provide an API for them that would harmonize with the higher-order bisection procedure. But I can definitely see why that would be desirable, so I’ll think about it.

> (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.

That would seem to me to be a matter of coding style. ;-) In any case, as I mentioned previously, if a comparator object *is* lying around, it's just a matter of calling comparator-ordering-predicate on it to get the procedure that this SRFI (and SRFI 132) wants.

Regards

Daphne