In March of this year, Shiro Kawai wrote:

> This may be too late for discussion, but I just wonder why
> make-rtd should be generative....
>
> The reason I can think of is that we need a way to create a
> distintive type.  But that can be achieved easiliy without
> requiring make-rtd generative, as I describe later.
>
> An alternative idea is to change definition of identity of
> rtd.  What if we define two rtds are eqv? if they have the
> same NAME, FIELDSPECS and eqv? PARENT?  (If we extend rtd to
> have sealed and/or opaque flags, we compare those flags as
> well).  In other words, we make make-rtd behave
> functionally, meaning it returns eqv? objects for equivalent
> set of arguments.

That could be done, but it's more complicated.

> In order to get distinctive types, we can add one more
> member to rtd; let's say it uid.  It is an arbitrary Scheme
> object and is compared by eq? when comparing two rtds.  Then
> we can guarantee distinctive type by passing an object that
> can't be eq? to other objects, such as (cons #f #f).

In both drafts of SRFI 99, as in the R6RS library document,
the uid argument is used to specify non-generative record
types.  You are proposing to reverse that by using the uid
to specify generative record types.  That presupposes some
generative source of uids, such as cons.

> This scheme seems to have advantages over R6RS way when we
> want non-generative behavior: (1) It makes bookkeeping of
> rtd's identity implicit, as opposed to the explicit identity
> specified by R6RS.  The R6RS way effectively introduces a
> separate namespace for rtd, which doesn't seem to "fit" to
> other parts of Scheme spec, at least to me.  (2) It
> eliminates the need of something like UUID in some cases
> for non-generative make-rtd.

With regard to (1), it seems to me that your proposal also
introduces a separate global table, although it isn't a
"namespace" because it involves hash-consing (using eqv?
identity) on *all* arguments to make-rtd.  That's more
complicated, and more fragile with respect to inadvertent
retention, than maintaining the smaller table whose entries
represent only the non-generative record types, and are
indexed by uid symbols.

So I don't see the advantages to your proposal, and I do
see some disadvantages.

Will