On 23 Jul 2021, at 13:48, Lassi Kortela <xxxxxx@lassi.io> wrote:

> I'm very much in favor adding operations on abstract datatypes into the canonical set of Scheme procedures (on some timescale, no rush). But if we do, we should do it in a way that is compatible with CLOS, JVM, and CLR.

Yes, this would probably be a better and more consistent approach to the whole problem, in my opinion.

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. This is also automatically not compatible with CLOS, the JVM, and the CLR, though that could be worked around in ways similar to the 'even cleverer' solution I mentioned above.

John has given a very sensible reason why he wants to get dictionaries standardized before the next ballot for R7RS: he doesn’t want more SRFIs and more R7RS libraries defining procedures that only work on one key-value mapping type (be it alist or hash or whatever). However, if generic functions would be a better way of solving this in general, perhaps ‘some timescale’ should considered ‘as soon as possible’. This doesn’t mean work on SRFI 225 has to stop, of course — but we could have two options on the ballot. The other alternative is that we just accept that future SRFIs accepted for R7RS will initially be defined to only work on one dictionary type until generic functions/interfaces are worked out, and we go back at the end (during the Ultraviolet ballot process) and fix them all to use whatever generic dictionary interface solution we adopt.

Daphne