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