I'm not aware of a Scheme that supports expand-time overloading in its
type system. Expand-time overloading would require a static type system,
or at least an incremental type system with inference. And implementing
that kind of inference in macros would require Turing-complete logic in
macros that, while *technically* possible to implement in portable
syntax-rules, would be a nightmare to write.

SRFI 213 properties are at least a step in the direction of type
inference as a possibility. But type systems are the kind of thing that
individual Schemes are likely to want to implement in their own,
mutually-incompatible ways. (So are object systems, but runtime object
systems are more likely to have some minimal subset of common features,
whereas static type systems rarely ever do.) I don't think R7RS large
should define anything like a fully static type system, even as an
optional library.

Simple expand-time overloading with SRFI 213 might be possible,
though... it could be an optional feature of a hypothetical object
system SRFI. A runtime, CLOS-like object system, with the optional
feature of expand-time overload resolution based on *very simple*
optional SRFI 213 type annotations. Very limited generics and very
little inference (maybe parameters in procedure signatures, but no
parameterized types), so that it's not overspecified.

On 10/8/20 1:46 PM, Marc Nieper-Wißkirchen wrote:
> Maybe we should first answer the question *why* we want to have a
> common API for all, say, sequence-like data types. There are a couple
> of answers to this, some more convincing than others, but in any case,
> it will depend to a not inconsiderable extent on the answers given in
> which direction we will have to proceed.
>
> For example, there is compile-time overloading and runtime
> overloading. Compile-time overloading is like Java's generics or C++'s
> template system. Runtime overloading is known well from classical OOP.
> The C++ people have been moving from the latter to the former. The
> latter is more flexible but it will probably noticeably less efficient
> than the former.
>
> That's why I think we should do some research in that area first.
> Runtime-overloading (as in the many Lisp/Scheme object systems) has a
> lot of examples and is somewhat well-understood. Expand-time
> overloading and the exploitation of the Scheme macro system in this
> regard is a more novel idea but it may lead us much farther. We can
> possibly have generic algorithms that are no less efficient than
> algorithms individually crafted for each type.
>
> tl;dr No rush job, let's evaluate first and do it optimally.
>
> Am Do., 8. Okt. 2020 um 19:32 Uhr schrieb Adam Nelson <xxxxxx@nels.onl>:
>> I agree that the prefixed datatypes are a mess and that subtyping would
>> help. I've been considering putting together an object system SRFI,
>> likely based on one of the many CLOS-like systems in Scheme. It should
>> be possible to find some broadly-compatible subset of features out of
>> the many CLOS-like object systems out there, and with the right
>> limitations on multiple inheritance it may even be possible to implement
>> it on top of Kawa's JVM object system too.
>>
>> These individual datatype SRFIs with prefixed procedures will still be a
>> necessary first step, though. The interface methods can be based on
>> them. Once an object system SRFI is approved, a common container
>> interface SRFI could be imported without having to import them individually.
>>
>> On 10/8/20 1:23 PM, Per Bothner wrote:
>>> I accidentally replied the following to just Arthur, but meant to send
>>> it to a wider audience:
>>>
>>>      I've said it before, and I'll said it again: Having all these
>>> distinct datatypes
>>>      with distinct APIs and no subtyping is bonkers.
>>>
>>>      Nothing against this particular SRFI, which is just another
>>>      example of a bad approach to design a language.   Common Lisp did
>>> this
>>>      much better in 1984.
>>>
>>> Arthur agreed that "we should [probably] have a subtyping mechanism",
>>> and encouraged proposals along these lines.  However, there is no point
>>> unless these are a significant number of users and implementors who
>>> feel the same.
>>>
>>> This means not just designing an API for defining types and classes,
>>> but also re-thinking and slimming down SRFI 214 and a dozen collection
>>> APIs to make use of sub-typing.
>>>
>>> I believe there is no point in continuing with r7rs-large on its
>>> current course
>>> without sub-typing; I think it is doomed to sink under its own weight.
>>>
>>> FWIW, Kawa's define-class/define-simple-class has the necessary
>>> functionality,
>>> but the syntax (based on Common Lisp) may not be to everyone's liking,
>>> and it has more tweaks and features than makes sense for a standard:
>>> https://www.gnu.org/software/kawa/Defining-new-classes.html
>>>
>>> What is needed IMO is a way to define "types" (interfaces)
>>> with multiple inheritance of methods (with optional default
>>> implementation),
>>> and no fields; and concrete "classes" that implement interfaces,
>>> have fields, and (probably) no inheritance.