ISSUE: DEFSTRUCT-SLOTS-CONSTRAINTS

[Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>]

I support DEFSTRUCT-SLOTS-CONTRAINTS-NUMBER:ALLOW-ZERO.
Btw, the benefits of this are more than just aesthetic. In the sample
error system I distribute with my proposal, there are examples of valid
uses for zero-element structs. Since such are disallowed, I conjure
one-element structs with a slot called -DUMMY-SLOT-. This means that
there is a loss space in spaces that really need no slots but are forced
to use at least one.

I have sympathy with DEFSTRUCT-SLOTS-CONSTRAINTS-NAME:DUPLICATES-ERROR
but will not claim to support it. I think it should be stronger:
implementations should be required signal an error or some well-defined
behavior should be described which implementations are forced to adhere
to. This is because there are conflicting ways in which extension might
be done, and having different implementations interpret the same syntax
in different ways without any kind of warning is a real barrier to
portability: it might be that neither implementation complains and code
simply behaves oddly in one implementation or the other. Programmers are
frustrated by this because neither implementation can be said to be the
bad-guy and yet it's clear that the programmer is getting screwed. Hence,
I think it's our charter to protect him. Requiring implementations to
signal an error is probably the simplest and most consistent solution.