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.
