[R6RS] R6RS records: non-generative record type descriptor identity

Marc Feeley feeley
Sat Aug 27 09:59:40 EDT 2005


The specification of make-record-type-descriptor contains this
passage:

     When make-record-type-descriptor is called repeatedly with
     the same uid argument (in the sense of eq?), all other arguments
     to make-record-type-descriptor must also be the same (in the sense
     of equal?), and the same record-type descriptor (in the sense of
     eq?) is returned every time.

To clarify the meaning of this passage, the meaning of equal? on type
descriptors (the parent argument) must be defined explicitly in the
specification.

Moreover I don't see why the same type descriptor (in the sense of
eq?) must be returned every time since there are no mutation
operations on type descriptors.  This constraint requires the
implementation to keep a table (e.g. a weak hash table) of the record
type descriptors in the system.  This is a burden (in implementation
complexity) for some Scheme implementations.  We could define record
type equality using equal?, i.e. two record type descriptors represent
the same record type iff the record type descriptors are equal?.  Of
course implementations of Scheme which have weak hash tables may
choose to return the same record type descriptor in the sense of eq?.

Concerning the constraint

     If a call with the same uid differs in any argument, an error
     is signaled.

I don't think the "name" argument should be considered to be part of
the type since "it has purely informational purpose".  I can even  
imagine
users varying the name of *a* given type based on linguistic preference.

Moreover, I would prefer "It is an error if a call with the same uid
differs in any argument." to allow implementation specific extensions,
such as documentation information that has a purely informational
purpose.

Finally, if we want to avoid gratuitous uid clashes, the specification
should advocate a procedure for choosing "unique" uids.  This is
motivated by our objective to allow easy sharing of code.  We could
for example suggest using symbols containing a UUID suffix (see
http://www.ietf.org/rfc/rfc4122.txt).

Marc



More information about the R6RS mailing list