Thank you for your quick reply, John!

Am Di., 20. Juli 2021 um 19:39 Uhr schrieb John Cowan <xxxxxx@ccil.org>:

On Tue, Jul 20, 2021 at 1:07 PM Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:

The `frob-dict` procedure is supposed to be a generically polymorphic procedure working on dictionaries. It does, however, exhibit an unpleasant ad-hoc polymorphism: It can turn a plist into an alist.

You're right; I wasn't thinking about the effect of deleting the last entry in a plist. The Right Thing, I think, is to have a plist-specific SRFI (we already have the code for it) and exclude it from dictionaries.

This solves one problem.  However, we still have the following problems related to lists:

(1) No user can later register plists because the empty list is already registered as an alist, meaning that SRFI 225 won't be able to support all well-known Scheme/Lisp  dictionary types.

(2) Alists are still restricted to the `equal?' key comparator, which is too restrictive for general code.  One can try to remedy this by adding just another dynamically scoped parameter, say, `current-alist-equality-predicate' but this makes reasoning even harder and can cause a further slow-down. Moreover, it will become inconvenient as soon as code has to deal with two different types of alists in parallel.

Unless another mechanism is employed (for example a type descriptor as the first argument), one of the two list dictionary types should be removed from the SRFI.

That was my original design: the same as comparators, since dictionaries are also a type class. I'll discuss this further in my response to your other post.

Why have you abandoned this design? While it looks slightly less convenient, it's benefits over the many drawbacks of SRFI 225's current approach outweigh the extra parameter by light years.