On Tue, Aug 4, 2015 at 5:01 AM, Jean-Claude Beaudoin < [email protected]> wrote:
> > > On Tue, Aug 4, 2015 at 4:54 AM, Kenneth Tilton <[email protected]> wrote: > >> >> >> >> On Tue, Aug 4, 2015 at 3:55 AM, Jean-Claude Beaudoin < >> [email protected]> wrote: >> >>> >>> >>> On Mon, Aug 3, 2015 at 10:12 PM, Peter Stirling < >>> [email protected]> 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 [email protected] http://tiltontec.com @tiltonsalgebra 646-269-1077 "In a class by itself." *-Macworld*
