Re: Record proposal

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

> I don't much care about the order of the fields, it is an issue of
> performance, not ability.  The constructor could be keword-based as in
> CL if you do not want to give any status to the order of the fields.

We could, but we'd want to maintain equivalence between the strings
passed to make-record-type and the strings used as arguments to
record-field-accessor/mutator, so we might as well maintain the
ordering in this case too and keep constructors returned by
record-constructor positional (and therefore simpler and consistent
with constructors generated by define-record).

I'm inclined to say that the list of field names returned by
(record-field-names (make-record-type s ls)) is element-wise eqv? to
ls.  On the other hand, this guarantee should not hold for descriptors
extracted from records.

The order of arguments to a constructor returned by record-constructor
can mirror the order of field names returned by record-field-names in
either case.

> BTW, I'm just curious.  Why did you want to leave the equivalent of
> make-record-type and the constructor out?  It should not get in the
> way of programs that use define-record.

Simplicity, partly, and partly because, as an implementor, I'd prefer
to force people to use a mechanism I expect to be able to generate
efficient code for over one that I'm not sure I can generate efficient
code for, all other things being equal.

> In fact, it seems to me that the proposal can be simplified somewhat.

> I am assuming here that if a field is inaccessible in one instance of
> a record type, it is inaccessible in all instances of the same record
> type (past and future).  Let me know if I am wrong in this assumption.

> Thus, record-type-field-names (or whatever it is called) can just not
> provide that field name at all, since such fields are unobservable.
> Thus any field would be accessible, but not necessarily mutable.

This would work, but I was operating under a different assumption.  A
compiler may determine through flow analysis that a field of a specific
record is no longer accessible, and I'd like for the system to be able
to drop the field (or more likely, its contents) without worrying about
access via the abstraction breaking mechanism.  We do exactly this for
the contents of frames.  Flow analysis could also determine that, from
a given point in a computation, a field is no longer mutable.

The mechanism I proposed also permits an inspector, for example, to
determine fields that have been eliminated, which might be useful
information to present to the user.

I'm not committed to this, however.  I started with the interface you
describe, although I found it necessary to include a
record-field-mutable? predicate.

> The same thing happens with constructors.  If a compiler has decided
> to eliminate some field, the constructor that it returns will match
> the fields that are actually there, so the missing field won't exist
> as far as the "abstraction breaking" facilities are concerned.

Good point.  Of course, positional parameters specifying values to
nonexistent fields can be ignored as well.

> OK.  However, although the program is incorrect, it may very well work
> on many implementations (which won't bother to reorder the field
> names).  I think that you are trying to legislate style, and that is
> usually unsuccessful, but since I don't care much either way, it's
> fine with me.

I'm not sure I'd dismiss it as a matter of style, but okay.  I'm trying
to make it clear that programmers should use the accessors and mutators
generated by define-record if they want to manipulate specific fields,
i.e., that the ones obtained by way of record-descriptor are intended
for meta programming purposes only.