On 24 Jul 2021, at 06:26, John Cowan <xxxxxx@ccil.org> wrote:

> Go with A or with B?  Why not both, however you please to use them?
> <snip>
> Well, if someone turns fast generics into a SRFI implementation (writing the SRFI text will be easy) along the lines I've sketched, we can get them on the next ballot or two -- but there is no reason for them to be mutually exclusive.

If the point of dictionaries is to establish a standard way to talk to key-value mapping objects regardless of their implementation, which will be used in future SRFIs and Scheme libraries, then surely it *is* a question of whether our approach to that particular question looks more like SRFI 225 (in its new incarnation with user-specified dictionary type descriptors) or more like CLOS/fast-generics/whatever?

>> However, generic functions in Scheme have many of the same performance issues as the SRFI 225 (first draft) registration system. Since the only portable typing mechanism we have are predicates, not type descriptors, the only easy way for many implementations to do typing dispatch is calling each predicate in turn.
>
> Fast-generics allows you to specify predicate subsumptions, which is isomorphic to subtype relationships.  If the predicate P1 subsumes P2, then the type of objects satisfying P2 is a subtype of the type of objects satisfying P1.  So when doing fast-generics on top of a JVM/CLR style type tree, we extend the subsumption relation to know about its subtypes, and then we can cleverly make use of its built-in dispatching.

Yes, but predicates can be arbitrary Scheme procedures in a way that type descriptors corresponding to Java classes/etc can't be, making this trickier. (I guess we make it ‘an error’ to use a predicate which isn’t one of a disjoint type as defined in the spec or created by define-record-type or whatever procedural records layer we adopt?)

Daphne