Re: Record proposal

["R. Kent Dybvig" <dyb@cs.indiana.edu>]

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

I was really hoping to leave it out, although I understand why you feel
that it's necessary.  We'd need to add record-constructor as well, and
I assume we'd need to be more specific about the order of the field
names in a record descriptor. Or we might have make-record-type return
two values: a descriptor and a constructor.

> 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.

If I know that the field named by the first <field-id> in a record
definition is the field I want to access, and the field names returned
by record-type-field-names are given in the same order as the
<field-id>s in the record definition, I can simply write:

    ((record-field-accessor
       (record-type-descriptor x)
       (car (record-type-field-names x)))
     x)

to obtain the contents of that field.  This is what I meant by
"positional access".

> 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.

You're right, the positional layout to which I implicitly referred is
the syntactic layout of <field-id>s in the record definition, not the
layout of fields in the record.

Kent