Issue:               DEFSTRUCT-COPIER
References:          DEFSTRUCT
Related issues:
Category:            CLARIFICATION, CHANGE
Edit history:        V1, 10 May 90, Sandra Loosemore
                     V2, 13 May 90, Sandra Loosemore (update discussion)
		     V3, 29 May 90, Sandra Loosemore (more comments)

Problem description:

The description of the :COPIER option to DEFSTRUCT in CLtL
states:

   The automatically defined copier function simply makes a new
   structure and transfers all components verbatim from the argument
   into the newly created structure.

This description doesn't make it clear whether the type of the
newly created structure is copied from the argument, or is
determined by the copier function.  This can make a difference
in the case where a copier function defined for one structure
type is passed an argument that belongs to a subtype of the
original type.  Does the result have the "name" of the subtype
and any additional slots present in the subtype but not the
parent type, or does it have the same "name" as the parent 
type and only the slots inherited from that type?

There are four proposals:  ARGUMENT-TYPE, COPIER-TYPE,
UNSPECIFIED, and REMOVE.


Proposal (DEFSTRUCT-COPIER:ARGUMENT-TYPE):

  Clarify that the type of the result returned by copier functions 
  created by DEFSTRUCT is always exactly the same type as the 
  argument to the copier.  That is, if the argument is of a
  subtype of the structure type for which the copier was defined,
  then the result will also be of that subtype and include all
  the slots of the subtype.

  Rationale for proposal ARGUMENT-TYPE:
    Some people expect this behavior.


Proposal (DEFSTRUCT-COPIER:COPIER-TYPE):

  Clarify that the type of the result returned by copier functions 
  created by DEFSTRUCT is always exactly the structure type for 
  which the copier was defined.  That is, if the argument is of a
  subtype of the structure type for which the copier was defined,
  the result will be of the supertype only and include only those
  slots that are present in the supertype.

  Rationale for proposal COPIER-TYPE:
    Some people expect this behavior.


Proposal (DEFSTRUCT-COPIER:UNSPECIFIED):

  Clarify that it is unspecified whether the type of the result 
  returned by copier functions created by DEFSTRUCT is the type
  of the argument to the copier, or the structure type for which the
  copier function was defined.  (In other words, the behavior of
  copier functions is well-defined only when they are passed
  arguments of the exact same type for which the copier was
  defined.)

  Rationale for proposal UNSPECIFIED:
    Some people don't know what behavior to expect.


Proposal (DEFSTRUCT-COPIER:REMOVE):

  Remove the :COPIER option to DEFSTRUCT.

  Rationale for proposal REMOVE:
    The feature is so poorly specified it's already useless.
  

Examples:

    (defstruct foo a b)
    (defstruct (bar (:include foo)) c d)
    (setq result (copy-foo (make-bar)))

  Under proposal ARGUMENT-TYPE,
    (type-of result) => BAR

  Under proposal COPIER-TYPE,
    (type-of result) => FOO

  Under proposal UNSPECIFIED,
    (type-of result) => either FOO or BAR

  Under proposal REMOVE, users would have to define their own
  copier functions to have whatever behavior they wanted.

    
Current Practice:

  Some Lisps now implement proposal ARGUMENT-TYPE and others implement 
  proposal COPIER-TYPE.  Some Lisps also provide a COPY-STRUCTURE
  function that can be used to make an exact duplicate of any
  structure object.

Cost to Implementors:

  Small.

Cost to Users:

  Code that relies on any particular behavior is probably not now
  portable anyway.  It doesn't seem like copiers are used very
  much.

Cost of non-adoption:

  This part of the language specification remains vague.

Performance impact:

  Proposal REMOVE would save space since there would be no
  normally useless copier functions generated by DEFSTRUCT.
  It may be that copier functions defined by hand would be
  considerably less efficient than a copier provided by the
  implementation (which might make use of knowledge about the
  internal layout of structures to do a block memory copy or the
  like).

Benefits:

  This part of the language specification becomes more precise.

Esthetics:

  Leaving the behavior explicitly vague seems unnecessarily ugly.

Discussion:

  Loosemore's ranking of the proposals from most to least
  acceptable is:  ARGUMENT-TYPE, REMOVE, COPIER-TYPE,
  UNSPECIFIED.

  BarMar has said he thinks the behavior should be left
  unspecified.

  Moon has said he favors flushing the :copier feature.  Barrett
  also prefers flushing :copier.

  Perhaps we should consider adding COPY-STRUCTURE to the
  standard?
-------
