Proper behavior of slot-initforms in defstruct?

[Kenneth Tilton]

On Tue, Aug 4, 2015 at 5:01 AM, Jean-Claude Beaudoin <
jean.claude.beaudoin at gmail.com> wrote:

>
>
> On Tue, Aug 4, 2015 at 4:54 AM, Kenneth Tilton <ken at tiltontec.com> wrote:
>
>>
>>
>>
>> On Tue, Aug 4, 2015 at 3:55 AM, Jean-Claude Beaudoin <
>> jean.claude.beaudoin at gmail.com> wrote:
>>
>>>
>>>
>>> On Mon, Aug 3, 2015 at 10:12 PM, Peter Stirling <
>>> peter at pjstirling.plus.com> wrote:
>>>
>>>> My read of the spec is that either behaviour is allowable.
>>>>
>>>>
>>> The two behaviors are so different that I have a hard time accepting
>>> this.
>>>
>>
>> The issue is not the degree of behavior difference, the issue is the
>> degree to which the language of the spec constrains an implementor.
>>
>> Did Peter miss this, or am I missing something completely (I am just a
>> simple application programmer): "The slot default init forms are evaluated
>> in the lexical environment in which the defstruct form itself appears and
>> in the dynamic environment in which the call to the constructor function
>> appears.
>>
>
> It seems that Peter and I both missed it somehow.
>

I missed it, too, the first 2-3 times. Then I happened to look back at the
section and there it was as plain as day. Perception is like that.


> That clears the issue pretty clearly;
> clisp wins and all the others, well...
>

No, CLisp loses (a little*).

In the dynamic environment of the execution of your top-level (make-bar)
example the variable serial-no is unbound, so evaluating the initform (incf
serial-no) should fail as you documented.

The CLisp source is available, AFAIK. I suspect we would discover that the
initform is implemented as an anonymous function that closes over the
lexically available serial-no at definition time, and that the :include
option does not copy the slot *definition* and then proceed with struct
compilation*, instead it copies the compilation* and hence the same closure
over the same serial-no.

* Probably relevant: Clisp is interpreted.

-hk


>
> Thank you very much Ken for pointing this key sentence.
>
> Case closed.
>
>


-- 
Kenneth Tilton
54 Isle of Venice Dr
Fort Lauderdale, FL 33301

ken at tiltontec.com
http://tiltontec.com
@tiltonsalgebra

646-269-1077

"In a class by itself." *-Macworld*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/pro/attachments/20150804/1f33462d/attachment.html>