[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
    From: Pavel.pa@Xerox.COM


    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
discussed this:

  (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


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


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


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.