[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Issue: DEFSTRUCT-SLOTS-CONSTRAINTS-NAME , Version 4



I think this proposal is too weak in its criterion for considering
slot name "conflict" to be an error.  The ONLY effects of slot name choice
over which the programmer has no control are:
1) the determination of the slot accessor function symbol
   (but this is determined not solely by the print name of the symbol; the
    :conc-name and value of *package* also come into play.)

2) the keyword arguments for a keyword constructor.  Maybe the parameters
for a BOA constructor as well, but CLTL is mute about whether the
correspondence between the BOA constructor formal parameters and the
symbols used to designate slot names is by name equality (string=), or
by EQ, in which case the package matters.  In

3) the way the default #S printer prints things.

I prefer to think of slot names as symbols, not strings.  CLtL in fact
says the slot name must be a symbol.  This proposal seems to move toward
saying that all that matters is the symbols symbol-name, in which case why
not allow a string as the slot name in DEFSTRUCT?  I had always assumed
that, with a conc-name of NIL, the accessor for the slot would be the symbol
I used as the slot name; not a symbol in *package* with the same name.  If
I am right, then the fact that two slots have the same symbol-name does not
imply any conflict in the accessor.

I think something should be considered an error only if we are unable or 
unwilling to specify its effects -- not because we consider it bad style.
So, I would be happy to say that "it is an error" to hand the reader
#S<C ... :foo value ...> for a defstruct class C having multiple slots named
FOO.  
I would also be happy with -- in fact I would like it -- a proposal that
said "it is an error" for defstructs of two different classes or two slots
of the same class to yield the same accessor functions (in the case of
two different classes regardless of whether one includes the other).  Notice
that this can occur even if the slot names differ:
(defstruct (fab (:conc-name "FAB")) junk cd)
(defstruct (fa (:conc-name "FA")) bcd more-junk)
 both of these are specified to create an accessor FABCD in *package*.  Should
we just say that whichever one happens last is the definer of FABCD, or call it
a (not necessaily signalled)  error?

Since another cleanup proposal has proposed allowing defstruct constructors
to have &key in their lambda lists, even two slots of the same structure
with the same name (but different pkgs) could be suitably distinguished,
since &key allows you to specify the formal parameter name and the 
"keyword" used in calls differentially.

I wouldn't object to the proposal if the
criterion for conflict were simply symbol equality, rather than name equality, 
although it would still leave unaddressed accidental conflicts like the one 
mentioned above.


Neil