ISSUE: DEFSTRUCT-SLOTS-CONSTRAINTS

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

I have divided the issue DEFSTRUCT-SLOTS-CONSTRAINTS into 2 issues,
DEFSTRUCT-SLOTS-CONSTRAINTS-NUMBER and DEFSTRUCT-SLOTS-CONSTRAINTS-NAME,
even though they are both trivial, because otherwise practically every 
section of the proposal had 2 parts, and also it seemed reasonable to
separate a change from a clarification, for approval purposes (actually the
main reason is that I couldn't think of a name for the joint proposal).

Issue:          DEFSTRUCT-SLOTS-CONSTRAINTS-NUMBER
References:     CLtL p.307 & 86-003 p.4
Category:       CHANGE
Edit history:   Revision 1 by Skona Brittain 05/13/88


Problem Description:

Structures defined by defstruct currently are required to have at least
one slot.  This seems to have been a mistake in the design of the language.


Proposal (DEFSTRUCT-SLOTS-CONSTRAINTS-NUMBER:ALLOW-ZERO):

Allow a call to defstruct to have zero slot-descriptions.
i.e. change the + to a * in the syntax of calls to defstruct 
given at the bottom of page 307 of CLtL.


Test Case:

(defstruct s), which is not allowed according to CLtL, would be allowed.


Rationale:

The current restriction is in marked contrast to the generality allowed 
elsewhere in the language.  And removing it slightly increases the 
usefulness of defstruct - by allowing the zero slot case when it may be 
deemed useful and by not requiring a check for it when it doesn't matter.


Current Practice:

KCL allows zero slots.  


Cost to Implementors:

None for implementations that currently allow zero slots.
Very slight for others.


Cost to Users:

None.


Benefits:

Slightly increases the usefulness of defstruct and is aesthetic.


Aesthetics:

In general, it is more aesthetic to allow for generality rather than to
specifically prohibit a particular case.  And the generality in this case 
is consistent with that of many other features of the language, such as 
that arrays can be empty, functions like + and list can take zero arguments, 
etc.


Discussion: 

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



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


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.


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.  Checking for it
would be costly so signaling this error is not required.


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.