Defstruct :include with :conc-name

[jch]

Consider the following code, which is a simplified version of stuff that can be found in CL-Yacc:

(defstruct item x)
(defstruct (sub-item (:include item) (:conc-name item-)) y)

The ANSI CL spec explicitly states that this is allowed, in the description of :CONC-NAME in the description of DEFSTRUCT. However, CCL generates a warning:

;Compiler warnings for "/home/pps/jch/struct-test.lisp" :
;   In an anonymous lambda form at position 18: Duplicate definitions of ITEM-X, in this file

It would appear that CCL generates correct code, but I believe that this is by accident.

[gb]

You're right; this case (where the use of :CONC-NAME would create a duplicate accessor for an inherited slot) is covered in the last paragraph of the discussion of the :CONC-NAME option in the entry for DEFSTRUCT. COMPILE-FILE's warning about a duplicate definition that shouldn't have been generated.

[rme]

We no longer warn about this, but we still appear to generate an item-x accessor when defining sub-item.

[rme]

(my earlier comment about no longer warning about this is wrong.)

From  http://clozure.com/pipermail/openmcl-devel/2009-October/010668.html

Compiling a file with the following contents, both with 1.3 and with trunk (r12863):

 (defstruct foo
   (bar nil))

 (defstruct (foo1 (:conc-name foo-) (:include foo (bar t)))
   (frob nil))

generates a full warning about a duplicate definition of foo-bar within the same file. However, the second defstruct should not generate a definition of foo-bar at all, because foo-bar is already a reader for the bar slot in the (inherited) structure foo. (See the last paragraph of the :conc-name section in CLHS defstruct).

[rme]

(In [13590]) Don't generate duplicate accessors for inherited slots. (See ticket:390)