ISSUE: DEFSTRUCT-SLOTS-CONSTRAINTS-NAME

[Skona Brittain <skona%csilvax@hub.ucsb.edu>]

Issue:          DEFSTRUCT-SLOTS-CONSTRAINTS-NAME
References:     CLtL p.308 & 86-003 p.4
Category:       CLARIFICATION
Edit history:   Revision 1 by Skona Brittain 05/13/88
                Revision 2 by Skona Brittain 07/26/88 (incorp.June discussion)


Problem Description:

The case of two slots of a structure having string-equal names, which
is obviously fraught with ambiguity, is not discussed in CLtL.


Proposal (DEFSTRUCT-SLOTS-CONSTRAINTS-NAME:DUPLICATES-ERROR):

It is an error for two slots in a structure type to have string-equal names.
This holds when they were both named directly by the same call to defstruct
or when one is present by virtue of being in an included structure.


Test Cases:

(I)                        (III)
(defstruct struc           (defstruct struc1 
   slot                       slot)
   slot)                   (defstruct (struc2 (:include struc1)) 
                              slot)

(II)                       (IV)
(in-package 'foo)          (in-package 'foo)
(defstruct struct          (defstruct foo-struct
  slot1                      slot1)
  bar:slot1)               (in-package 'bar)
                           (defstruct (bar-struct (:include foo:foo-struct))
                             slot1)


Rationale:

Since it would be difficult to prescribe (or even imagine) reasonable 
behavior for this situation, it should be considered an error.  


Current Practice:

Sun Common Lisp 2.0.3 detects attempts to define structures with string-equal 
slots at defstruct expansion time, even if the conflicting slot comes from 
inheritance.

Symbolics Common Lisp in Genera 7.2 and Kyoto Common Lisp June 3, 1987 
don't notice the conflict and different kinds of haphazard behavior ensue.
At least in KCL, the details differ between the various test cases above.


Cost to Implementors:

None.


Cost to Users:

None.


Cost of Non-Adoption:

Possible confusion.


Benefits:

Clarity.


Aethetics:

Something that is not well-defined and leads to erratic behavior 
should be explicitly considered an error.


Discussion: 

Kent thinks this proposal should be strengthened, either by specifying
a particular odd behavior to ensue or, preferably, by requiring the error 
to be signaled (or perhaps even signalled). 

Skona thinks that is too strong.  This error is on par with many others 
in CL that need not be signaled (such as defining a function with 
string-equal argument names).  The cost of the checking does not seem worth it.

Barry suggests that we facilitate including a structure defined in 
a different package without worrying about string-equal names 
by allowing non-keyword symbols to be used as slot name "keywords" 
(i.e. as keyword arguments to the constructor/accessor functions)
as in the extension to keyword argument syntax that was done for CLOS.  
(If this proposal is thusly modified, we should also add a requirement
to the default printed representation of structures that the slot names 
get printed with their package prefixes.  Maybe something should be said
anyway to standardize whether the slot names or the associated keyword
symbols are printed.)

Larry thinks that that alternative is going in the wrong direction: rather 
than enhance defstructure, we should let it do the simple stuff efficiently 
and have CLOS provide the extra power & flexibility when necessary.