Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> writes:
> This is not related to the concept of hygiene associated with the
> strip-syntax problem. The latter comes into play when a macro wants to
> instantiate a private plus:
>
> (define-syntax foo
>   (syntax-rules ()
>     ((_)
>      (begin
>        (define-generic (plus ...) (...))
>        (plus 1 2)))))
>
> (define-generic (plus ...) (...))
> (foo)
>
> The macro's plus will interfere with the main plus, although it should have
> no knowledge about it.

Yes, I see. I would've thought that was cool, but I see.

As an aside, why I was so willing to accept so many restrictions on
where you can define your generics because I saw it as analogous to a
couple of other things with similar restrictions.

For example record types and their accessors, which you typically define
all at once.

Also the cond forms that it expands to, are de facto defined all at
once.

But a robust super fast generics system would be awesome.

Btw, I don't use the cond-based generics myself since I made
https://idiomdrottning.org/mdg

Which has… A lot of similar issues but I'm still just playing around
with it. I only just made it yesterday.

> It doesn't solve the lexical scope problem for which you seem to need
> identifier properties. But it would allow you to remove strip-syntax,
> solving the macro hygiene problem from above.

Sure. seems to be a low-effort fix (if I only had a bound-identifier=? available).

So to implement identifier properties it's not sufficient to have a
symbol database, right?

> If you want to reverse or filter a vector, number made of digits, or a
> string, they all have something in common, namely that they model a
> sequence-like type. (In Haskell, you would have a type class). So you don't
> want to have a fully generic interface across all types but only across
> types that model a sequence.

Yes. Similarly, you can compare all comparable types. This is what I
mean by scenario A.

> Now, the only question is how to model such a model-type relationship. SRFI
> 128's answer is to use things like comparator objects, that is something
> like Haskell's type classes in a dynamic version.
>
> It's good that the way a concrete type models an abstract one (like a
> sequence) is spelled out explicitly because, in general, there is no
> default relationship. For example, for a number, you can consider its
> decimal digits or its digits to any other base.

Yes, in Haskell you can easily make a procedure that turns a number into
a sequence of ones and zeroes that you can then filter, map, reverse etc
to your hearts content.

>> 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.
>>
>
> Sorry, my mistake. I meant comparator-type-test-predicate.

comparator-equality-predicate

And yes. This is used internally and is then later "uncurried".

> What do you mean by this?

If you see two strings you can use their types to look up what
comparator to use.

But, if you see the numbers 2 and 3 you don't know what ring multiplier
is appropriate since they belong to several possible rings.

Therefore, in the comparator case it is possible to dispatch on args
directly which is not possible in the matrix example.

> Well, you could then even have
>
> ((ring-element-* (matrix-ring ring)) m1 m2)

Do you mean e1 and e2? Then yes. Otherwise no.

>> (frob)
>
> Can you explain what you mean here?
>
> If I understand correctly, your macro redefines the binding of frob, and
> library B cannot see the rebound frob of library C.

I guess I meant (find-frob)

But we're back to a dynamically bound proc which is difficult to
optimize at compile time. Similar to SRFI-128.
So other solutions are interesting.