Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> writes:
> (NB: Equal? is not always a substitute for eq? or eqv?. The equivalence
> relation defined by it is coarser.)

Yes.

(let ((horse "horse")) (eq? horse horse)) ⇒ #t
(eq? "horse" "horse") ⇒ #f

What I was trying to say is that people sometimes use equal? when they
should be using string=?, and that the solution to that isn't to give a
longer more cumbersome name to equal?.

Scheme isn't a better language if equal? is renamed

equal-are-you-sure?-you-know-about-string=?-right?-so-why-are-you-using-this-one?

Deliberately cumbersome names to encourage efficient code is not
something I'm onboard with.

> > In order to write efficient Scheme code it's important to know when to
>> use equal? and when to use type-specific comparison.
>>
>> Similarly, it's important to know when to use a generic =? and when to
>> use string=?
>>
>
> Equal? is much less generic than a generic =?. It is much more akin to
> string=? in this regard.

That's why I wrote "similarly" instead of "identically".

> Yes, this is very much like equal? because it is essentially a static
> dispatch, which can quite easily be optimized by the compiler. This is
> not the case for the default comparator mechanism of SRFI 128.

Right.

Having a dynamic injectable comparator is less optimizable. Which is an
argument in favor of (=? x y) over (=? comp x y).

You specifically requested:
> I may be more persuadable if you can show how to prevent that code using
> your interface doesn't become highly inefficient.

And I complied by providing an implementation of (=? x y) that's more
efficient than (=? comp x y).

I've got to say that there's been some amount of goal-post-movery and
burden-shouldering-over-placery in this discussion.

At every turn I've been asked why I would want the interface I suggest.
And, when complying (for example by saying that it can slot right into a
sort, map, or count, and that that's saying something about the
interface's idiomaticality, or by providing use cases and examples),
that has been met by new requests.

Including "show how to prevent it from becoming highly inefficient".
Which I have.

> (NB: Due to the use of strip-syntax, your macro lacks hygiene. This is
> irrelevant for the current discussion but otherwise relevant.)

It does not inject the syntaxed-stripped names into the environment.

The syntax-stripped names are used as symbols to store things in a
hash-table and look things up in said hash-table.

The generic procedure names that are bound into the environment are not
stripped.

>> So, let's keep the three different scenarios separate:
>>
>> • A. truly generic generics over an extensible type record object
>> • B. generics over a supplied subset that only need to dispatch between
>>      a handful of types, such as monster sprites vs player sprites
>> • C. type-specific monomorphic comparators such as string=?
>>
>> You can not use the speed of scenario C to argue against scenario A.
>> Let's be clear about that.
>>
>
> I don't understand what you want to say here, nor do I understand what
> exactly you mean by point A. Something like define-generic that you linked
> or a fully dynamic runtime registry as in SRFI 128?

Either of those two can be used to satisfy scenario A.

Scenario A: making generic code without limiting it to a particular
domain or particular set of types.

Scenario B: making code that needs to be polymorphic over a handful of
types, but those types are known.

Scenario C: making monomorphic code. I.e. making string=? or monster=?

The reason I bring up the differences between those scenarios is to
clarify that when we are talking about inefficient algorithms for
scenario A, those "inefficiencies" aren't compared to scenario C, which
is a completely different use case and set of requirements.

> I'm not sure whether this is your point but if you want to say that a
> generic =? that expands into a cond clause is a viable alternative to =? as
> specified by SRFI 128, I can possibly agree.

I especially want to say that the (=? x y) interface can be implemented
a lot more efficiently than (cut =? (make-default-comparator) <> <>)

(I used the name frob in my sample above since it's binary while a true
=? would be variadic.)

> What I have been disagreeing about is that a fully dynamic =? using
> the dynamic default comparator as a default is very helpful.

While I have the opposite position, that I'm not sure how useful
(=? insert-comparator-here x y) would be in practice.

To rephrase one of the things I wrote previously:

It's very expensive to pass and read the type record in the arg list
like that.

The hope in doing that is to net gain performance by having the type
record be small and tight and domain-specific.

The existence of a net gain there is something I am disputing (except
for cases that are *so* tight that you'd not want to use this comparator
interface in the first place for them).

Not to take away from my main point which is, again, that the interface
is cumbersome and does not easily slot into existing combinators like
sort, map and count.