Proper behavior of slot-initforms in defstruct?

Laughing Water lw at mt.net
Mon Aug 3 21:42:05 UTC 2015


It looks like you need a LET* to guarantee the order of evaluation within your LET. Otherwise, it’s undefined.

Laughing Water

> On Aug 3, 2015, at 3:27 PM, Jean-Claude Beaudoin <jean.claude.beaudoin at gmail.com> wrote:
> 
> 
> Please consider the following code:
> 
> (defparameter init-a 1)
> 
> (let ((init-a 42) (serial-no 0))
>   (defstruct foo (a init-a) (b (incf serial-no)))
>   (defun get-foo-serial-no () serial-no))
> 
> (defstruct (bar (:include foo)) (c 33) d)
> 
> When one loads the above and then try to call #'make-bar the result
> varies widely from one lisp implementation (clisp) to another.
> 
> clisp: (make-bar) --> #S(BAR :A 1 :B 1 :C 33 :D NIL)
> ccl: (make-bar) --> <enter the debugger saying: "Unbound variable: SERIAL-NO">
> 
> lispworks, allegro and sbcl also behave more or less like ccl.
> 
> What is the proper ANSI-CL behavior in this case here?
> Is clisp right in evaluating the slot initform in its "proper" lexical context?
> Or is the correct behavior to replicate the slot initform verbatim
> in the sub-structure constructor regardless of its original lexical context
> like the others do?
> 
> I guess that this question has probably been asked before, in a somewhat
> distant past, but my google skills have not been sharp enough to find it, sorry.
> 
> 




More information about the pro mailing list