Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> writes:
> I don't think it's unfair. :) If a technical argument proves that some
> version for which you want the shorter name is better than the other, the
> issue will be trivially resolved. The point from above is only relevant if
> one version isn't clearly technically superior.

To be specific, you previously wrote:
> I may be more persuadable if you can show how to prevent that code using
> your interface doesn't become highly inefficient.

I did do so.

> If you just want (=? "hi" "hi") to work, then everything is solved.

Good. That's alla I wanted.

> I would say that (=? default-comparator "hi" "hi") is too inefficient for
> general use outside some corner cases.

Yes.

>> I wasn't clear on how that the preceding was a problem.
>>
>
> If a macro locally instantiates a renamed "plus", it will modify the
> registry of a top-level (not renamed) "plus", whereby violating hygiene.

To be specific, here is what I believe would happen:

(define-generic (plus ...) (...))
(define-generic (plus ...) (...))
(define-generic (plus ...) (...))

(let my-cozy-scope (...)
 (define-generic (plus ...))
 (define-generic (plus ...))
 (plus...)) ; ← the inner version of plus, with five clauses

(plus ...) ; ← the outer version of plus, with three clauses

Now, if a sixth plus were to be defined here, things would bork because
it unhygienically see the inner-scope stuff, which could break.

> So what you need is a hash table whose equivalence predicate is
> bound-identifier=?.

This is interesting. How would that solve the issue?

> Have you taken a look at identifier properties to solve this?

I took a quick glance. Yes, it seems to overlap with what I am trying to
do here.

> Scenario A is most probably irrelevant for practical purposes. In basic
> Haskell you cannot even code scenario A; nevertheless there is no doubt
> that all practical algorithms can be mapped well to Haskell.

Scenario A is awesome. Being able to write algorithm that works the same
across types is sweet. For example being able to reverse a vector, a
number or a string as easily as a list. I have previously made as-list
for this purpose:

((as-list (c filter odd?)) 130752)
⇒ 1375

((as-list cdr reverse) 23311358)
⇒ 5311332

((as-list delete-duplicates) 23311358)
⇒ 23158

((as-list append) 11 22)
⇒ 1122

(define (vowel? l) ((as-list (c member l)) "aeiou"))
((as-list (c filter vowel?)) "magnetic mountaintop")
⇒ “aeiouaio”

> Discussing the interface before the semantics is dangerous.

I like to work from both directions. I sometimes notice that I've made a
bad interface and then I go back and change it so that it's better.

> On the other hand, if you really want the (=? x y) interface, it
> somehow dictates the semantics because the comparator registry would
> be too slow, leaving only your idea of define-generic.

Or other, more robust generics systems.

>> ((ring-element-* integer-ring) 2 3) of course.
>>
>> (ring-element-* integer-ring) ⇒ *
>>
>> (ring-element-* xyzzy-ring) ⇒ frobnicate
>>
>> Alternatively, if you wanna do SICP style message passing case dispatch
>> instead of generics:
>>
>> (integer-ring 'ring-element-*) ⇒ *
>>
>> (xyzzy-ring 'ring-element-*) ⇒ frobnicate
>>
>> ((quotient-ring r i)  'ring-element-*) ⇒ (lambda (a b) (+ i (* a b)))
>>
>> This is a good interface because we can then use maps, reduce etc to
>> implement our matrix operators, which we can't (directly) if
>> ring-element heterogenously contains the dispatching type record.
>>
>
> SRFI 128 does give you this style of interface. It's comparator? instead of
> =?.

This is incorrect. Comparator? in SRFI-128 is a predicate to test
whether or not something is a comparator. That is not analogous to what
I propose for the ring properties.

> But what would the analog of your =? be in the matrix example?

As you know, with comparators their types are readily available but with
ring members their group memberships aren't.

The interface I proposed for the matrix example would therefore be
either

(ring-element-* integer-ring) which evaluates to *

if we use a generics-looking record accessor, or

(integer-ring 'ring-element-*) which evaluates to *

if we use SICP-style message passing case dispatch.

To be very specific about the difference:

You proposed
(ring-element-* integer-ring x y)

I preferred:

((ring-element-* integer-ring) x y)

This is easier to implement and easier to use with maps and reduce.

Similarly, I prefer ((matrix-* ring) m1 m2) over (matrix-* ring m1 m2)

>> That works, but, yes, it is not an elegant solution to this problem. A
>> sexp-based lisp1 with a robust and fast generics system would be an
>> awesome thing to behold♥
>>
>
> I meant the following problem: Library A provides your generic frob.
> Library B exports a procedure, say, amplifier, that calls the generic frob.
> Now, library C defines a new type, say a monster, that it wants to amplify.
> So it adds (by your recipe above) an extra entry for frob and calls library
> B's amplifier. But how does library B's amplifier see the amended frob?

Not an easy thing to solve when amplifier is a lexically closed
procedure defined in a separate syntactical unit. Solutions welcome.