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