Issue: DEFSTRUCT-SLOTS-CONSTRAINTS-NAME (Version 2)

[masinter.pa@Xerox.COM]

I've modified the proposal to say that it "should signal an error". This is shakey ground, but the sentiment from all that responded is that error-signalling is the desired behavior. I don't think the current "situations" language covers the distinction between macro expansion and evaluation, but I hope that we can invoke the distinction by reference and hope that it will appear in the standard...


!
Issue:          DEFSTRUCT-SLOTS-CONSTRAINTS-NAME
References:     CLtL p.308 & 86-003 p.4
Category:       CLARIFICATION

Edit history:   Version 1 by Skona Brittain 05/13/88
                Version 2 by Larry Masinter 14-Sep-88

Problem Description:

The case of two slots of a structure having the same name 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 the same name.
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.

The situation of expanding a DEFSTRUCT macro with a duplicate name should
signal an error. (While not yet formally defined, the intent is that 
the error signalling may occur when compiling a file that contains
duplicate names or when evaluating a DEFSTRUCT form with duplicate names
in an interpreter.)

Test Cases:

(defstruct struc slot slot) would be an error.  So would
(defstruct (struc2 (:include struc1)) slot) if preceded by
(defstruct struc1 slot).

Rationale:

Since it would be difficult to prescribe reasonable behavior for
this situation, it should be considered an error.

Current Practice:

In KCL, if 2 slots have the same name, no warning message is 
given but mysterious behavior ensues.  (Their default values are 
both whatever is given for the second one, neither can be given a
different value via a call to the constructor function, only the 
second one's value can be changed by setf...)

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: 

Although this issue was mentioned in Guy's original issues file, it has
not been officially discussed since.  

This issue was first circulated to X3J13 June 1988.