DEFSTRUCT and lexical environment
in [Lisp]
|
From: Tim Bradshaw on 14 Oct 2009 14:10 On 2009-10-14 02:44:53 +0100, Ron Garret <rNOSPAMon(a)flownet.com> said: > 5. The fact that at least one member of the ANSI committee (Dan > Weinreb) has gone on the record to say that the spec is ambiguous. For what it's worth, here is another one saying the same thing. (I don't claim Dan's authority, and I was not on the committee until after the standard was finished.)
From: Tim Bradshaw on 14 Oct 2009 14:13 On 2009-10-14 11:17:41 +0100, Madhu <enometh(a)meer.net> said: > I believe he means "He" did not think about this. I believe he means that nobody thought of it.
From: Alan Bawden on 14 Oct 2009 14:13 Vassil Nikolov <vnikolov(a)pobox.com> writes: > > I do not agree, but at this time it seems to me that only designers > of DEFSTRUCT, members of the standardization committee, or > implementors can make further useful contributions to this thread. In the version of DEFSTRUCT that I wrote in 1978 (that everybody used before we had Common Lisp), the initforms were just substituted directly into the code generated by the constructor macro. That wasn't very pretty, but most of the time it didn't matter because initforms contained nothing but constants and global variables. It would have been hard to do better, because I had to support MacLisp (which had no closures!). The language in the Common Lisp specification that you are all discussing is there because the committee recognized that the initform behavior of my original DEFSTRUCT was undesirable, and that those forms really should be treated as expressions that were tied to the lexical environment in which they originally occurred. It is true that the interaction with :INCLUDE wasn't explicitly spelled out (almost certainly because the issue didn't occur to the committee at the time) but it is clear that their -intent- was to elevate those forms from contextless fragments of code into true expressions that could refer to the lexical environment in which they occurred. It would be a weirdly perverse reading of the specification (and history) to claim that the committee only wanted to go half-way towards making initforms true expressions by giving them a new lexical environment each time their containing DEFSTRUCT is :INCLUDEd.
From: Tim Bradshaw on 14 Oct 2009 14:20 On 2009-10-14 02:29:49 +0100, Ron Garret <rNOSPAMon(a)flownet.com> said: > There is no :include construct for DEFCLASS (and hence no corresponding > ambiguous specification) so I don't see how this is relevant. That's so, but the nearest equivalent works (in the way we both believe to be) right: (let ((x 3)) (defclass foo () ((s :accessor foo-s :initform x)))) (let ((x 4)) (defclass bar (foo) ()))
From: Madhu on 14 Oct 2009 17:46
* Alan Bawden <w2dd44pyhbm.fsf(a)shaggy.csail.mit.edu> : Wrote on 14 Oct 2009 14:13:33 -0400: | In the version of DEFSTRUCT that I wrote in 1978 (that everybody used | before we had Common Lisp), the initforms were just substituted directly | into the code generated by the constructor macro. That wasn't very pretty, | but most of the time it didn't matter because initforms contained nothing | but constants and global variables. It would have been hard to do better, | because I had to support MacLisp (which had no closures!). | | The language in the Common Lisp specification that you are all | discussing is there because the committee recognized that the initform | behavior of my original DEFSTRUCT was undesirable, and that those | forms really should be treated as expressions that were tied to the | lexical environment in which they originally occurred. So this issue about which lexical environment the inintform is evaluated _did_ come up. | It is true that the interaction with :INCLUDE wasn't explicitly | spelled out (almost certainly because the issue didn't occur to the | committee at the time) Given they had your implementation, the claim (if a committe member so makes it now) that this thought did not occur to ANYBODY in the committee AT ALL is both preposterous and impossible to believe, now since you also state that the motivating reason for including the wording [regarding lexical environments] in the first place was from hygiene considerations. | but it is clear that their -intent- was to elevate those forms from | contextless fragments of code into true expressions that could refer | to the lexical environment in which they occurred. The spec as it stands today defines how the initforms are substitued [verbatim, the alternative makes no sense] into the optional arguments of MAKE-STRUCTURE constructor forms of the _included_ structure which are built up in the defstruct macro. | It would be a weirdly perverse reading of the specification (and | history) to claim that the committee only wanted to go half-way | towards making initforms true expressions by giving them a new lexical | environment each time their containing DEFSTRUCT is :INCLUDEd. Regardless of intent, the definition in the spec today [based on your implementation] is both reasonable and it provides a predictable model for behaviour of code, especially in the face of side effects which are not prohibited by the language, and given the facts that the language does not make hygiene its prime directive. And has a defmacro system (which is also used for including code fragments) that behaves in a similar way. -- Madhu |