[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Record proposal



|   Date: Mon, 29 Apr 1996 10:18:00 -0500 (EST)
|   From: "R. Kent Dybvig" <dyb@cs.indiana.edu>
|   Cc: rrrs-authors@martigny.ai.mit.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.

On the first reading, I did not notice that the constructore was
missing.  Yes, we would need it as well.

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.

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.

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.

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.

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

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.