I've not yet contributed to srfi-discuss before I believe, so hello!
This topic interests me greatly, so I figured I'd jump in where I could.

>     • overloading of arithmetic operators
>
>
> Possibly typeclass Num.

I am actually quite intrigued by this discussion, although I may not be
as helpful for commenting on Scheme-ish ways to do things, since I
mostly just use CHICKEN exclusively, except when I use Guile.

Problems like this in Rust, for example, are handled by having
type-classes (called traits in Rust) for Add, Multiply (Mul), etc. for
each operation you may want to overload.

Beyond that, separate traits are available for set! style assignment as
well: AddAssign, MulAssign, etc. This is interesting because some types
implement the Add trait, but not the AddAssign trait, so you can get
some kind of generic guarantee that a type is
100%-not-going-to-be-mutated-no-matter-what (tm) (c) (R).

The idea of breaking up standard functionality via type-classes across
the language seems overwhelming, but is actually quite elegant in
practice, for Rust.

I bring up Rust here because some of the ways traits model things are
maybe a better fit for Scheme than Haskell is. Haskell is interesting
and informs Rust with many of its foundations, but Rust has actual
mutability (as Scheme does) whereas Haskell does not. My experience is
that Haskell is very formal in its definitions as a result, which maybe
makes some of the ideas harder to approach because you have to get over
a lot more jargon vs. how static dispatch on a trait occurs.

>
>     Arithmetic operator overloading seems to me to be of very marginal
>     value in the context of Scheme.
>
>
> Quaternions.

The geometric product and geometric algebra are a pretty good fit for
this in general, as the main thing limiting performance tends to be type
hierarchies & type dispatch. However, that doesn't necessarily mean that
+, -, *, /, et al. need to be valid symbols or procedures that can be
overloaded.

> <https://github.com/johnwcowan/r7rs-work/blob/master/ContextsCowan.md
> <https://github.com/johnwcowan/r7rs-work/blob/master/ContextsCowan.md>>
> is the Haskell typeclasses Monad, ApplicativeFunctor (aka Idiom), and
> Functor.  Another interface could combine Monoid, Semigroup, Group, and
> possibly some other group theory stuff: Haskell has all that.
>

I think there's roughly two kinds of "generics" out there:

   1. Haskell / Rust style static dispatch based on type-classes.
   2. CLOS / JVM / Python / vtable-like dynamic dispatch based on
      (sub-)types.

The former is IIUC a bit more generalizable than the latter. However,
that is mostly true in the context of Haskell / Rust, where the type
system does most of the heavy lifting. Remember that many type-class
based systems are very much used for static dispatch, which to me always
felt like it was very much not the easy paradigm to utilize with a
language as dynamic as Scheme or Lisp. Like comparators, you end up with
a bunch of records and then have to do much of the management of these
records on your own. CLOS doesn't have this problem, because you don't
add new types, you add new methods, which are called similarly and
dispatch "magically" based on types. In Haskell/Rust, you make new types
and calling conventions are handled AOT by the compiler (what I meant by
"the types do the heavy lifting"). At the core of it, you run into the
expression problem.

As mentioned before, there is no such portable (type-id ...) in Scheme,
which means one will end up running into a wall quite easily regardless
of which approach is taken. On the other hand, it is entirely possible
to design a type class for a portable / extensible (type-id ...) that
can register direct types. The implementation may not be fully portable,
but the API would be. This would mostly be constrained by how much
effort someone wanted to spend to port this SRFI, and I would personally
argue that portability is fine to sacrifice considering the challenges
involved.

 From there, one could very quickly build a CLOS-style dispatch system
that utilizes that single type-class for (sub-)typing. This feels more
natural for a Lisp / Scheme to me than e.g. comparators do today, but
maybe that's some kind of survivorship bias speaking.

Either way, having one ugly, not-portable type-class to establish type
identities, and then using that as the basis for creating a portable
CLOS system seems like /one possibility/ for such a system, and I find
it interesting. Otherwise I think you run into the lack of type-id, and
the "non-portability" or performance problems of e.g. predicates creep
into literally everything else.

> In the meantime, I'm also pursuing fast-generics, which will gives us
> dual, indeed complementary, approaches to generic behavior: generic
> functions and typeclasses.

As much as this is maybe "too little too late": I think there's a lot of
precedent for type-class style code in SRFIs already. Comparators are a
type-class, as previously mentioned (although they encode Eq, Ord, and
Hash, which is 2 more than you would normally expect for a single type
class). There's also storage classes in SRFI 179. Sequence APIs like
what Clojure has could also be a type class, but the actual
implementation is sub-typing based, and depends on the underlying JVM.

But that probably contradicts some of what I said earlier with regards
to how type-classes come out feeling awkward in Scheme as comparators
sometimes do. We don't have a compiler that is taking type-classes and
automatically inserting them into the right arguments for us, so it
feels like trying to solve the issue from the wrong side of the
expression problem.

Needless to say, I think the lack of generic interfaces are something
that really splits Scheme from a lot of "modern" languages. That's not
necessarily a bad thing, but I agree with others here that this is an
important problem to tackle.

Cheers,
--
Jeremy Steward