Re: Generative record types

[kelsey@research.nj.nec.com (Richard Kelsey)]

   Date: Tue, 23 Apr 1996 23:21:32 -0500 (CDT)
   From: Shriram Krishnamurthi <shriram@cs.rice.edu>
   References: <199604232248.RAA02997@europa.cs.rice.edu>
	   <23Apr1996.223316.Alan@LCS.MIT.EDU>

   Alan Bawden <Alan@lcs.mit.edu> wrote:

   >			    Unfortunately the proposal that you make doesn't
   > immediately seem very different to me from the `make-record-type' proposal
   > that we have -almost- agreed to on several previous occasions.

   Chances are there are no substantive differences, only (mostly)
   syntactic ones.  Perhaps define-struct can be defined as a macro on
   top of make-record-type; 

Yes.

   Richard Kelsey once kindly provided me with a macro for define-structure
   atop define-record-type.

No, I implemented it on top of the make-record-type procedure.
One advantage of a procedural interface to making new record
types is that it simplifies defining macros for defining record
types.

   >								  How does
   > this proposal address the concerns that have caused `make-record-type' to
   > repeatedly fail to pass?

   Perhaps it would help me and others who have been on the sidelines if
   someone (you?) could summarize why those proposals failed in the past
   (and how, if at all, those proposals differed from ours).

I have appended an earlier proposal to the end of this message.
This proposal was the result of a discussion on rrrs-authors.

   My impression, gleaned from sampling past discussions, is that a
   lot of discussion centered around issues like opacity.  We tried
   to explicitly deflect attention from that.

At the last meeting a record proposal, which if I remember
properly was similar to the one below, deadlocked over opacity.
The pro-opacity camp insisted on opacity and their opponents
insisted on its absence.

I prefer the proposal below, either with or without opacity,
to one based on additional syntax.
                                          -Richard


--------------------------------

Date: Fri, 01 Sep 89 13:50:16 PDT
From: Pavel.pa@xerox.com
To: RRRS-Authors
Cc: Pavel.pa@xerox.com
Subject: Programmer-defined data types, last (?) version

[... some discussion deleted by Kelsey ...]

=====================
We propose adding the following procedures to Scheme:

(MAKE-RECORD-TYPE type-name field-names)

Returns a ``record-type descriptor'', a value representing a new data type,
disjoint from all others.  The type-name argument must be a string, but is
only used for debugging purposes (such as the printed representation of a
record of the new type).  The field-names argument is a list of symbols
naming the ``fields'' of a record of the new type.  It is an error if the
list contains any duplicates.  It is unspecified how record-type
descriptors are represented.

(RECORD-CONSTRUCTOR rtd [field-names])

Returns a procedure for constructing new members of the type represented by
rtd.  The returned procedure accepts exactly as many arguments as there are
symbols in the given list, field-names; these are used, in order, as the
initial values of those fields in a new record, which is returned by the
constructor procedure.  The values of any fields not named in that list are
unspecified.  The field-names argument defaults to the list of field-names
in the call to MAKE-RECORD-TYPE that created the type represented by rtd;
if the field-names argument is provided, it is an error if it contains any
duplicates or any symbols not in the default list.

(RECORD-PREDICATE rtd)

Returns a procedure for testing membership in the type represented by rtd.
The returned procedure accepts exactly one argument and returns a true
value if the argument is a member of the indicated record type; it returns
a false value otherwise.

(RECORD-ACCESSOR rtd field-name)

Returns a procedure for reading the value of a particular field of a member
of the type represented by rtd.  The returned procedure accepts exactly one
argument which must be a record of the appropriate type; it returns the
current value of the field named by the symbol field-name in that record.
The symbol field-name must be a member of the list of field-names in the
call to MAKE-RECORD-TYPE that created the type represented by rtd.

(RECORD-UPDATER rtd field-name)

Returns a procedure for writing the value of a particular field of a member
of the type represented by rtd.  The returned procedure accepts exactly two
arguments: first, a record of the appropriate type, and second, an
arbitrary Scheme value; it modifies the field named by the symbol
field-name in that record to contain the given value.  The returned value
of the updater procedure is unspecified.  The symbol field-name must be a
member of the list of field-names in the call to MAKE-RECORD-TYPE that
created the type represented by rtd.

(RECORD? obj)

Returns a true value if obj is a record of any type and a false value
otherwise.  Note that RECORD? may be true of any Scheme value; of course,
if it returns true for some particular value, then RECORD-TYPE-DESCRIPTOR
is applicable to that value and returns an appropriate descriptor. 

(RECORD-TYPE-DESCRIPTOR record)

Returns a record-type descriptor representing the type of the given record.
That is, for example, if the returned descriptor were passed to
RECORD-PREDICATE, the resulting predicate would return a true value when
passed the given record.  Note that it is not necessarily the case that the
returned descriptor is the one that was passed to RECORD-CONSTRUCTOR in the
call that created the constructor procedure that created the given record.

(RECORD-TYPE-NAME rtd)

Returns the type-name associated with the type represented by rtd.  The
returned value is EQV? to the type-name argument given in the call to
MAKE-RECORD-TYPE that created the type represented by rtd.

(RECORD-TYPE-FIELD-NAMES rtd)

Returns a list of the symbols naming the fields in members of the type
represented by rtd.  The returned value is EQUAL? to the field-names
argument given in the call to MAKE-RECORD-TYPE that created the type
represented by rtd.

=====================
Notes on the proposal
=====================

-- The procedure RECORD? is necessary to allow reliable use of the
procedure RECORD-TYPE-DESCRIPTOR.

-- The type-name argument to MAKE-RECORD-TYPE is constrained to be a string
in order to allow experimentation with interesting semantics for other
kinds of values there.  One possibility raised in the discussion in May and
June of 1988 was some kind of a ``handler'' procedure, as in T objects.

-- We do not propose any general macro for the definition of record types.
The feeling is that this is not easy to do in a way that is both elegant
and sufficiently flexible.  Once we have macros, the primitives above
should be sufficient for portable experimentation.

-- The issues of subtyping and inheritance, print methods, and integration
with modules and/or
environments (e.g., Pascal's WITH construct) have been purposely avoided in
order to achieve more rapid consensus.  Designs for adding single
inheritance appeared in the discussion in 1988.

-- EQ? and EQV? treat records in the same way as they do pairs, vectors,
and strings.  EQUAL? is equivalent to EQV? on records.