PS I forgot to mention one more conceptional problem with the current SRFI 225 approach of basing its polymorphism on the type of the arguments: From a higher point of view, there is no conceptional difference between nullary or higher-arity constructors in the context of algebraic data types. As much as, say, (lambda () '()) is a constructor for alists, so is (lambda (alist k v) (cons (cons k v) alist)). SRFI 225, with its current approach, however, has to draw an unnatural line between constructors taking no argument of the dictionary type and constructors actually taking such an argument.

Am Di., 20. Juli 2021 um 19:21 Uhr schrieb Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de>:
The current draft of SRFI 225 uses a global registry to support polymorphism.

As it is well-known, this comes with a number of problems:

- Being global, the registry inherits some of the usual problems with global variables.
- The registry is much like a bunch of dynamically-scoped variables, whose problems we know from early Lisp dialects.
- The registry is shared across the whole Scheme process, meaning that libraries shouldn't register types (automatically), but only the user program should (see the related discussion on SRFI 128 comparators). This works until two previously separate user programs are merged together.
- Alists and plists can not be supported reliably together; see my other post.
- That SRFI 225 allows implementations to pre-register dictionaries makes it impossible to write portable code because if I, say, register SRFI 125 hash tables as a user, I may provoke an error because they have already been pre-registered.
- The same Scheme type can only be used in one way as a dictionary.
- The biggest problem, however, comes last: As the registry is a runtime object, an optimizing compiler has no way to optimize any generic access. This will make the SRFI 225 procedures way (!) slower than using type-specific procedures. This is especially problematic because SRFI 225 looks very convenient, drawing many users to it. But as it is now, it will be a honey pot.

So... coming to the title of this post: I would like to strongly ask the authors to think of a different mechanism to achieve polymorphism.

A certainly better way in all regards (apart from an extra argument) is to employ dictionary type descriptors bundling the predicate and accessor procedures of a dictionary type in a record.

-- Marc