Other SRFIs may not build on SRFI 225 directly but may use the ideas, e.g. to model abstract sequence types. These other SRFIs may also have more per-type predicates than "one".
SRFI 225 doesn't attempt to deal with general sequences. I have some inchoate designs for that, loosely based on the Squeak Smalltalk Collections API. It will be analogous to SRFI 225 but not an extension of it; in particular, there will be a hierarchy of typeclasses rather than just one.
Which is far from optimal.
Optimal is not my purpose. Usable is.
Unless everything is to be doubled, generic code using the current draft of SRFI 225 will have to thread the dictionary object through anyway. So an L-U interface is not worse but better for generic code.
Threading within non-primitive generic code would be reasonable. Threading through the non-generic code that calls generic code with specific dictionary objects is another matter. If this outer code is written purely in terms of hash tables, say, there is no reason to have to call generic non-SRFI procedures in L-U style.
I wouldn't necessarily adopt the solution I have proposed for SRFI 146 to SRFI 125 because if one needs functional updates for hashed dictionaries, one should use SRFI 146 hashmaps in the first place. And if only a SRFI 125 hash table is given, it just has to be copied once into a SRFI 146 hashmap.
And copied back, potentially.
So far, I haven't been disproved that turning the constant DTDs into procedures returning DTDs (and that take comparators and other type-specific arguments) is a good solution to all this.
Okay, supposing I want to write my own type-specific procedure returning a DTD: what DTD-construction primitives other than make-dtd should be provided to make that as easy as possible? This is the sticking point that comes to mind.
PS A completely different point: Has anyone yet thought about allowing SRFI 222 compound objects containing a DTD as well as DTDs? This will be extremely helpful for future extensions but it will need an efficient implementation of SRFI 222 accessors.
Can you expand on this?