Issue DEFSTRUCT-COPIER-ARGUMENT-TYPE Writeup

Issue:        DEFSTRUCT-COPIER-ARGUMENT-TYPE

Forum:	      X3J13

References:   DEFSTRUCT (X3J13/92-102, pp8-5..6)

Category:     CLARIFICATION

Edit history: 07-Jul-93, Version 1 by Pitman

Status:		Proposal RESTRICT passed 11-1 on letter ballot 93-306.



Problem Description:


 The description of the :COPIER defstruct option doesn't say that the

 consequences of applying the defined copier to an object not of the

 structure type are undefined.


Proposal (DEFSTRUCT-COPIER-ARGUMENT-TYPE:RESTRICT):


 Change the first sentence of the second paragraph of the description

 of the :COPIER to:


   The automatically defined copier function is a function of one

   \term{argument}, which must be of the structure type being defined.


 In addition, the last sentence can be changed to the following:


   If the DEFSTRUCT :TYPE option was not used, the following

   equivalence applies:


    (<copier> x) = (copy-structure (the \param{structure-name} x))


Test Case:


 (DEFSTRUCT S1 A B C)

 (DEFSTRUCT S2 A B C)


 (COPY-S2 (MAKE-S1 :A 3)) => ??


 Before this proposal, it is possible to interpret the definition to say

 that #S(S1 :A 3) might be returned here.  This proposal makes it clear

 that the consequences are in fact undefined.


Rationale:


 This gives implementational freedom in a situation where no reasonable

 programmer would say that the behavior should be well-defined.  


Current Practice:


 LispWorks 3.1.0 signals an error in the test case (even in low safety code).


 Symbolics Genera 8.3 returns #S(S1 :A 3) in the test case.


Cost to Implementors:


 None.  This change is upward compatible.


Cost to Users:


 HOPEFULLY none.   It would be really ugly to imagine anyone taking advantage

 of the room that there is now.


Cost of Non-Adoption:


 The spec is less tight.


Benefits:


 Aesthetics.


Editorial Impact:


 Very small.


Aesthetics:


 Mostly the spec (and any resulting code) will be slightly cleaner this way.


Discussion:


 This change is in response to comment Margolin #8.


 Pitman doubts that anyone will actually abuse the loophole that 

 this comment is about, but think's it's reasonable to tighten things

 up just in case.