[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: cl-cleanup@SAIL.Stanford.edu
- Subject: ISSUE: DEFSTRUCT-SLOTS-CONSTRAINTS-NAME
- From: Skona Brittain <firstname.lastname@example.org>
- Date: Tue, 26 Jul 88 16:50:21 PDT
- Cc: SKONA@csilvax.ucsb
- Posted-date: Tue, 26 Jul 88 16:50:21 PDT
References: CLtL p.308 & 86-003 p.4
Edit history: Revision 1 by Skona Brittain 05/13/88
Revision 2 by Skona Brittain 07/26/88 (incorp.June discussion)
The case of two slots of a structure having string-equal names, which
is obviously fraught with ambiguity, is not discussed in CLtL.
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.
(defstruct struc (defstruct struc1
slot) (defstruct (struc2 (:include struc1))
(in-package 'foo) (in-package 'foo)
(defstruct struct (defstruct foo-struct
bar:slot1) (in-package 'bar)
(defstruct (bar-struct (:include foo:foo-struct))
Since it would be difficult to prescribe (or even imagine) reasonable
behavior for this situation, it should be considered an error.
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
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:
Cost to Users:
Cost of Non-Adoption:
Something that is not well-defined and leads to erratic behavior
should be explicitly considered an error.
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.