Programmer-defined data types

[Chris Hanson <cph>]

   Date: Mon, 21 Aug 89 11:34 PDT
   From: bawden.pa@xerox.com
   Line-Fold: no

       Date: Fri, 18 Aug 89 18:36:26 PDT
       From: Pavel.pa@Xerox.COM

       (RECORD-CONSTRUCTOR rtd)

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

   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.

I agree with this wholeheartedly.  I think this form of the
constructor-constructor is significantly more useful.

       -- 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?

If it is the case that there are advantages to both points of view,
then whatever is provided should support both.  I think Alan's
suggestion does this.