Issue MAKE-LOAD-FORM-SAVING-SLOTS Writeup

Issue:        MAKE-LOAD-FORM-SAVING-SLOTS

Reference:    X3J13/92-102, dpANS 12.24

                MAKE-LOAD-FORM, p.7-51

                MAKE-LOAD-FORM-SAVING-SLOTS, p.7-56

              X3J13/92-2102, Kevin Gallagher comment #2

              X3J13/92-3104, Kim Barrett comment #4

              X3J13/89-526, Issue LOAD-OBJECTS (Version 4)

              X3J13/91-485, Issue SLOT-VALUE-METACLASSES (Version 7)

Category:     CLARIFICATION/CHANGE

Edit History: Version 1, 1/5/93, Kim Barrett

              Version 2, 1/5/93, Kim Barrett (fix current practice)

              Version 3, 1/6/93, Kim Barrett

                (description is operational, move possible operators to notes)

Status:       Proposal NO-INITFORMS accepted, March 1993


Problem Description:


 The description of the function MAKE-LOAD-FORM-SAVING-SLOTS is expressed in

 terms of MAKE-INSTANCE, SETF of SLOT-VALUE, and SLOT-MAKUNBOUND, which is a

 mistake on several counts.


 1. It could be interpreted as indicating that slot initialization forms are

 to be executed, with the values of the slots then modified by SETF of

 SLOT-VALUE or SLOT-MAKUNBOUND.  This is not in the spirit of the overall

 proposal that introduced this operator, which talks about allocation via the

 function ALLOCATE-INSTANCE.  MCL2.0 in fact used that interpretation, and then

 received bug reports from users who expected initforms to not be executed.


 2. None of these operators are defined by this document as being applicable

 when the metaclass STRUCTURE-CLASS is involved.  A sufficiently literal

 reading could cause one to conclude that in fact this specification requires

 such applicability, which the committee explicitly decided against.


Proposal (MAKE-LOAD-FORM-SAVING-SLOTS:NO-INITFORMS):


 1. Replace the first paragraph of the Description section of the dictionary

 entry for MAKE-LOAD-FORM-SAVING-SLOTS with


  Returns \term{forms} that, when \term{evaluated}, will construct an

  \term{object} equivalent to \param{object}, without \term{executing}

  \term{initialization forms}.  The \term{slots} in the new \term{object}

  that correspond to initialized \term{slots} in \param{object} are

  initialized using the values from \param{object}.  Uninitialized \term{slots}

  in \param{object} are not initialized in the new \term{object}.

  \funref{make-load-form-saving-slots} works for any \term{instance} of

  \typeref{standard-object} or \typeref{structure-object}.


 2. Add the following to the Notes section for MAKE-LOAD-FORM-SAVING-SLOTS.


  When the \term{object} is an \term{instance} of \typeref{standard-object},

  \funref{make-load-form-saving-slots} could return a creation form that

  \term{calls} \funref{allocate-instance} and an initialization form that

  contains \term{calls} to \macref{setf} of \funref{slot-value} and

  \funref{slot-makunbound}, though other \term{functions} of similar effect

  might actually be used.


Editorial Impact:


 A small cut and paste job.


Rationale:


 Addresses the problem description.


Examples:


 (defvar *initform-executed-counter* 0)

 (defstruct foo

   (slot-1 (incf *initform-executed-counter*)))

 (defvar *foo* (make-foo))

 *initform-executed-counter* => 1

 (mapc #'eval (multiple-value-list (make-load-form-saving-slots *foo*)))

 *initform-executed-counter* => 1


Current Practice:


 Apple Macintosh Common Lisp 2.0p2 implements this.


Cost to Implementors:


 Probably small.


Cost to Users:


 Probably small.  Only programs that were depending on the execution of

 initforms would be negatively affected by this, and such programs are

 probably already not portable.


Performance Impact:


 None.


Benefits:


Aesthetics:


Discussion: