> DTDs (or DTOs as they are now called in John's repository head) are
> rather heavy objects when created through `make-dtd`.  This makes
> on-the-fly creation of such too costly.
>
> On-the-fly creation can be useful when one abstract type has to be
> coerced into another one.  Imagine that we not only have generic
> dictionaries but also generic sequences, which are described by a, say,
> STD.  Given a sequence of pairs, we may want to consider it as a
> dictionary, so offering a procedure `std->dtd` makes sense.
>
> A typical use case could be like in the following expression:
>
> (dict-set (std->dtd my-sequence-type) my-sequence obj ...)
>
> For this to make sense, `std->dtd` and thus DTD creations mustn't be
> necessarily costly.  One way to achieve this would be to add an
> auxiliary value to DTDs that can be inspected by the methods.  At DTD
> would then be the auxiliary value (like a SRFI 229-tag) together with an
> array of methods.  `std->dtd` would then reuse the same array of methods
> each time and just use a different auxiliary value.

I apologize for the drive-by criticism, but the main draw of generic
functions is that coders can type stuff like this:

foo.filter(odd?).each(write)

without being concerned with the types involved. The style of expression
is driven toward common English words; the machinery is hidden in the
background, and beginners don't have to be concerned with it. This is
why Smalltalk and Ruby are so friendly and easy to teach.

The DTD/DTO descriptors in the current draft, as well as the proposed
STDs, are going in the opposite direction. We're hardly doing any
abstraction (i.e. hiding); we mainly add more indirection, which exposes
more technical terms and acronyms to the user - never a good thing.

The present SRFI is solidifying my belief (which I formed recently,
thanks mostly to John's advocacy) that a proper Generic Scheme dialect
should be started. Thanks to the wonderful expressiveness of the RnRS
library system, it doesn't have to be a new language from the ground up
- we could simply write an alternative to `(scheme base)` exporting
generic versions of `length`, `append`, etc.

Optimizing generic function dispatch will be non-trivial, but the wider
Lisp community has decades of experience with it.

If we keep designing tailor-made solutions for each application of
generic functions / objects, Scheme will get increasingly bureaucratic
by accumulating large amounts of the "indirection, not abstraction" that
causes Java adepts to give up on that language.

In fact, one criticism made against Common Lisp is that it's not generic
enough. Many of its standard functions can only handle one type. E.g.
`intersection` can only intersect lists, not vectors.