Richard Kelsey writes:
>...
>    DEFINE-RECORD-TYPE is generative: each use creates a new
>    record type that is distinct from all existing types, including
>    other record types and Scheme's predefined types.

I might represent a very small portion of Scheme community that
thinks that nongenerativity has some benefits of its own, but for
few of us, it's a pity to lose a perfectly good SRFI because of
just one phrase.

I believe that for most applications the choice of generativity /
nongenerativity doesn't matter because records are only defined once.
>From the other hand, traditional interactive load-test-edit-reload cycle
becomes easier if existing record objects can still be recognized by the
corresponding predicates after reloading of the edited source file.

My old implementation of records used the following trick:
make-record-type first checked if the type being registered
has been registered before by checking the corresponding entry
in *record-type-table*. If the record was already there and
the field list was equal? to the new one, the old record type
was reused; otherwise, the new record type was created
and put into the table. This implementation was nongenerative
by default, but allowed for several useful options
to help in interactive debugging: before reloading the
source file, any number of entries could be removed
from the table; this made the system "partially generative".
Alternatively, one could set the *record-type-table*
variable to #f thus disabling all table operations and
turning the system into "fully generative" mode.

I call this a trick because the programs I used to write
were not dependent on the generativity/nongenerativity
of the implementation; they never defined the same record
type twice. However, having meta-linguistic control over
generativity issues made interactive debugging much easier.

Fixing the "generativity" issue either way once and for all
makes my implementation nonconforming. I would be much
happier if instead of the strict generative wording, this SRFI
used something like this:

  Records are disjoint from the types listed in Section 3.2 of R5RS.
  Record types produced by record type definitions with different
  <type name>s are disjoint. The relation between types produced
  by two record type definitions with identical <type name>s is
  implementation-dependent.

>
>    Record-type definitions may only occur at top-level (there are two
>    possible semantics for `internal' record-type definitions, generative
>    and nongenerative, and no consensus as to which to use).

There is the third choice: allow `internal' record-type definitions, but
leave the generativity of such definitions explicitly unspecified.
Again, many useful programs can be written, which do not rely on
this property of the implementation.

>
> - SET!ing any of the bindings introduced by DEFINE-RECORD-TYPE should
>  not affect the original values of the bindings.

I can hardly imagine anyone who can benefit from the knowledge
that set!ting :pare from your example to something else won't
affect the behavior of kons and kar; it seems to me that requiring
this property from all implementations will legalize this questionable
practice instead of discouraging it.

Leaving some aspects of behavior explicitly unspecified is an
underestimated but very useful technique...

Sergei