Proper behavior of slot-initforms in defstruct?

[Peter Stirling]

That makes no sense, the bindings in the let are independent.


On 03/08/15 22:42, Laughing Water wrote:
> 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.
>>
>>
>


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus