Record proposal

[Guillermo (Bill) J. Rozas <gjr@hplgr2.hpl.hp.com>]

I think we are approaching something that we could both agree on.  I
hope the same is true of the rest of the group.

I have a couple of questions, however:


1. You have omitted the equivalent of MAKE-RECORD-TYPE, which creates
a new record type.

Although the vast majority of uses of records will be through the
DEFINE-RECORD interface, the reason that MAKE-RECORD-TYPE is necessary
is the following:

Consider the task of writing an evaluator in portable Scheme.
The evaluator will have to handle occurrences of define-record
somehow.  Unless it can invoke an underlying evaluator, it cannot
create a record type compatible with the underlying implementation.

I would very much like it to be the case that a compatible
evaluator could still be written in Scheme, hence such an evaluator
will have to have the ability to construct record types on the fly.


2. I don't understand the following statement

    [Rationale: With field names as unique strings rather than symbols,
    abstraction-breaking code cannot access fields by name.  With the list
    of field names unordered, abstraction-breaking code cannot access
    fields by position.  This does not prevent the coding of generic
    inspectors and the like, but it does prevent programmers from building
    in dependencies on field names or positional values in code not within
    the scope of the record definition.]

Since record types are disjoint from vectors and strings (the only
indexed data types in Scheme), I don't see how positional access could
take place anyway.

In addition, again, because such record types are disjoint from any
other types in the system, I don't see how the order of the fields
has any relevance to the layout of the record.

I don't mind the restrictions that you have asked for, but I don't see
a reason for them.