The CL spec is mute on this point. If a destruct definition includes
another struct and the new struct has a slot with the name of a slot
in the included struct, what happens?
1. It's an error and the new struct can't be definded.
2. The new struct masks the included struct's slot.
3. It is #2 but the accessor for the new struct will access in the new
struct (ignoring the hidden original slot), and the original accessor
function will access the hidden in the included struct.
Example:
(defstruct person name age)
(defstruct (astronaut (:include person)) age position)
;;; the astronaut definition is either in error (redefining age slot)
;;; or it hides the person-age (perhaps with a warning)
(setf ex-one (make-person :name "Tom" :age 29))
(setf ex-two (make-astronaut :age 27 :position 'captain))
;;; the make-astronaut is either non-existent (the defstruct was in
error), or it works
;;; if we get to this point, what happens with the accessors
;;; everyone would agree that this works
(astronaut-age ex-two) => 27
;;; On the other hand, what happens if we use the person accessors
;;; is it -->
(person-age ex-two) => 27 or 29
My warped mind is inclined to allow hiding of an included slot. That
would mean that
(person-age ex-two) => 29
Is there a consensus among the various CLs? thanks
Jerry
On Aug 17, 2:40 pm, ···········@mac.com wrote:
> The CL spec is mute on this point. If a destruct definition includes
> another struct and the new struct has a slot with the name of a slot
> in the included struct, what happens?
> 1. It's an error and the new struct can't be definded.
I think it's not mute, but it's very obscure. It is (I think) an
error because duplicate slot names are not allowed. This:
http://www.lispworks.com/documentation/HyperSpec/Issues/iss119.htm has
an example where it is clear that this is an error. But the actual
spec does seem to not really mention it at all.
Tim Bradshaw wrote:
> On Aug 17, 2:40 pm, ···········@mac.com wrote:
>> The CL spec is mute on this point. If a destruct definition includes
>> another struct and the new struct has a slot with the name of a slot
>> in the included struct, what happens?
>> 1. It's an error and the new struct can't be definded.
>
> I think it's not mute, but it's very obscure. It is (I think) an
> error because duplicate slot names are not allowed. This:
> http://www.lispworks.com/documentation/HyperSpec/Issues/iss119.htm has
> an example where it is clear that this is an error. But the actual
> spec does seem to not really mention it at all.
It's in the exceptional situations section for defstruct:
"If any two slot names (whether present directly or inherited by the
:include option) are the same under string=, defstruct should signal an
error of type program-error."
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
On Aug 17, 7:01 pm, Pascal Costanza <····@p-cos.net> wrote:
> It's in the exceptional situations section for defstruct:
>
> "If any two slot names (whether present directly or inherited by the
> :include option) are the same under string=, defstruct should signal an
> error of type program-error."
Well found! So it's completely clear then!
On Aug 17, 4:28 pm, Tim Bradshaw <··········@tfeb.org> wrote:
> On Aug 17, 7:01 pm, Pascal Costanza <····@p-cos.net> wrote:
>
> > It's in the exceptional situations section for defstruct:
>
> > "If any two slot names (whether present directly or inherited by the
> > :include option) are the same under string=, defstruct should signal an
> > error of type program-error."
>
> Well found! So it's completely clear then!
Whew! Thanks folks for taking your time to dig it out. Specs can be
difficult.
Jerry
···········@mac.com writes:
> The CL spec is mute on this point. If a destruct definition includes
> another struct and the new struct has a slot with the name of a slot
> in the included struct, what happens?
> 1. It's an error and the new struct can't be definded.
> 2. The new struct masks the included struct's slot.
> 3. It is #2 but the accessor for the new struct will access in the new
> struct (ignoring the hidden original slot), and the original accessor
> function will access the hidden in the included struct.
>
> Example:
>
> (defstruct person name age)
> (defstruct (astronaut (:include person)) age position)
> ;;; the astronaut definition is either in error (redefining age slot)
> ;;; or it hides the person-age (perhaps with a warning)
>
> (setf ex-one (make-person :name "Tom" :age 29))
> (setf ex-two (make-astronaut :age 27 :position 'captain))
> ;;; the make-astronaut is either non-existent (the defstruct was in
> error), or it works
>
> ;;; if we get to this point, what happens with the accessors
> ;;; everyone would agree that this works
> (astronaut-age ex-two) => 27
>
> ;;; On the other hand, what happens if we use the person accessors
> ;;; is it -->
> (person-age ex-two) => 27 or 29
>
> My warped mind is inclined to allow hiding of an included slot. That
> would mean that
> (person-age ex-two) => 29
>
> Is there a consensus among the various CLs? thanks
Most of the implementations installed on my system signal an error such as:
; (DEFSTRUCT (A
; #)
; H
; N)
; Error: (during macroexpansion)
; Duplicate slot name N.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Our enemies are innovative and resourceful, and so are we. They never
stop thinking about new ways to harm our country and our people, and
neither do we. -- Georges W. Bush