[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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.