[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Programmer-defined data types
Date: Fri, 18 Aug 89 18:36:26 PDT
Returns a procedure for constructing new members of the type represented by
rtd. The returned procedure accepts exactly as many arguments as there
were slot-names in the call to MAKE-RECORD-TYPE that created the type
represented by rtd; these are used, in order, as the initial values of
those slots in a new record, which is returned by the constructor
I prefer the alternative that someone (RRJ?) made the last time we
(RECORD-CONSTRUCTOR rtd slot-names)
Where slot-names is a subset of the slot-names given to MAKE-RECORD-TYPE.
The returned procedure accepts exactly as many arguments as there are
slot-names. It creates a new record and initializes the specified slots.
Not only is this more flexible, but it is more readable. If you go looking
for the definition of MAKE-SPACESHIP and you find
(DEFINE MAKE-SPACESHIP (RECORD-CONSTRUCTOR SPACESHIP-RTD))
chances are your next move is to go looking for the definition of
SPACESHIP-RTD so you can figure out what the arguments to MAKE-SPACESHIP
are. Ugh. On the other hand, if you find
(RECORD-CONSTRUCTOR SPACESHIP-RTD '(NAME CAPTAIN)))
chances are good that you won't need to look any further.
Notes on the proposal
-- 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 1988
was some kind of a ``handler'' procedure, as in T objects.
Even if someday you can pass a ``handler'' to MAKE-RECORD-TYPE, mightn't
you -also- want to pass a type-name? I don't see how the two are
-- A case can be made that constructor procedures should take no arguments
and leave all slots in new records uninitialized. There appear to be
advantages to both points of view.
I'm not sure I understand why anyone would advocate this. Would such
people be made happy if
(RECORD-CONSTRUCTOR SPACESHIP-RTD '())
returns such a constructor? Or do such people think that the user should
be forced to use side-effects to initialize records?
-- ... The consensus of those I've spoken to concerning EQUAL? is that
it should be equivalent to EQV? on records, instead of treating them as
it treats vectors, pairs, and strings....
My personal preference: I have never wanted to compare records by
comparing their contents slot-by-slot. I -have- wanted to compare two
lists of records to see if they contain the same (EQ) records. The latter
application is at least slow and can also be dangerous if EQUAL? descends
records (the records may be part of a circular structure). That is why I
feel EQUAL? should not descend records.