#

## 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:

Copyright 1996-2005, LispWorks Ltd. All rights reserved.