From: Douglas K. <do...@go...> - 2014-01-17 21:18:42
|
COMMON-LISP-USER> (defstruct foo a b c) FOO COMMON-LISP-USER> (defstruct (kid (:include foo (b 5) (gaxr 'default))) a-new-slot) KID COMMON-LISP-USER> (make-kid) #S(KID :A NIL :B 5 :C NIL :A-NEW-SLOT NIL) I got bitten by thinking that a derived structure type was properly changing the defaulting expression for a slot in the ancestor. CLHS says of: (:include included-structure-name slot-description*) Each *slot-description* must have a *slot-name* that is the same as that of some slot in the included structure. |
From: Alastair B. <ala...@gm...> - 2014-01-20 14:15:27
|
Per CLHS 1.4.2, this example falls under "The consequences are undefined", meaning that if the implementation wants to signal a condition then it's welcome to, or if the system wants to play Angband instead (a classically #pragmatic gcc thing to do) then it's welcome to. On Fri, Jan 17, 2014 at 3:54 PM, Douglas Katzman <do...@go...> wrote: > COMMON-LISP-USER> (defstruct foo a b c) > FOO > COMMON-LISP-USER> (defstruct (kid (:include foo (b 5) (gaxr 'default))) > a-new-slot) > KID > COMMON-LISP-USER> (make-kid) > #S(KID :A NIL :B 5 :C NIL :A-NEW-SLOT NIL) > > I got bitten by thinking that a derived structure type was properly > changing the defaulting expression for a slot in the ancestor. > CLHS says of: > > (:include included-structure-name slot-description*) > > Each *slot-description* must have a *slot-name* that is the same as that > of some slot in the included structure. > > > > > ------------------------------------------------------------------------------ > CenturyLink Cloud: The Leader in Enterprise Cloud Services. > Learn Why More Businesses Are Choosing CenturyLink Cloud For > Critical Workloads, Development Environments & Everything In Between. > Get a Quote or Start a Free Trial Today. > > http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk > _______________________________________________ > Sbcl-devel mailing list > Sbc...@li... > https://lists.sourceforge.net/lists/listinfo/sbcl-devel > > |
From: Christophe R. <cs...@ca...> - 2014-01-20 14:24:41
|
Alastair Bridgewater <ala...@gm...> writes: > Per CLHS 1.4.2, this example falls under "The consequences are undefined", > meaning that if the implementation wants to signal a condition then it's > welcome to, or if the system wants to play Angband instead (a classically > #pragmatic gcc thing to do) then it's welcome to. Quality of implementation issues would prefer a compile-time full warning / run-time error, though :-) Cheers, Christophe |