Am Mi., 26. Mai 2021 um 09:48 Uhr schrieb Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de>:
Am Mi., 26. Mai 2021 um 09:35 Uhr schrieb Sandra Snan <xxxxxx@idiomdrottning.org>:
Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> writes:

> Maybe you can give us an example of the code you have in mind.

(map =? xs ys)

PS: For this use, something like

=?/default

would suffice while leaving the SRFI 128 specification of =? intact.

 

as opposed to

(map (cut =? comparator <> <>) xs ys)

Just as you can do

(map zero? xs)

as opposed to

(map (cut = 0 <>) xs)

The version with zero? is at least as performant as the version with (lambda (x) (= x 0)). This is highly not true for the =? case.

Again, which generic code do you have in mind where you want to code something like (map =? xs ys) and where using a user-supplied comparator argument is not the better solution?
 
>> Add1 and sub1 are a good analogies here, both which come in a version
>> without a default addend, too. + and - respectively.
>>
>
> The Scheme numeric tower is special. The arithmetic procedures are one of
> the few in Scheme that are ad-hoc polymorphic. But the Scheme number tower
> is fixed, so it is more or less just about one number type (which
> decomposes into a number of subtypes) and optimizing dispatch can be
> handled in a specific way (because the Scheme implementation knows its
> numeric types).

That is not quite what I was going after with add1.  I didn't meant to
bring up the whole float vs int thing. Instead, I meant an operator
where there is a default argument provided. 1 in the case of add1.

Add1 isn't part of the standard as far as I'm aware but it's proven
quite useful.

While I would rather spell (+ x 1) in full, I agree that versions with fixed arguments can be useful. For example, make-hash-table with a fixed eq-comparator argument (e.g. make-eq-hash-table) can be seen as useful.

The case of the default comparator, however, is one that shouldn't be the default- It can hardly be optimized by the compiler due to its dynamic nature.

> Relying on parameters would make the code even more inefficient (as
> would temporarily registering and restoring comparators, which would
> probably have to use dynamic-wind).

Yes. So having a version with a separate, longer name for those rare
occasions where you need to temporarily use another comparator could be
more efficient. It's rare that you need to edit the comparator and rarer
still that you need to edit it only temporarily, but, I don't want to
put hoops in place for those who want to do rare and unusual things. I
want to remove hoops for common and default things.

I agree with this. But using the default comparator should (despite its name) not be the common and default thing. :) Again, Scheme is not Python.