DEFSTRUCT and lexical environment
in [Lisp]
|
From: Pascal Costanza on 14 Oct 2009 17:59 Madhu wrote: > * 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. I find this very easy to believe. Such problems and the fact that they are discovered only very late occur all the time when defining languages or libraries. Pascal -- My website: http://p-cos.net Common Lisp Document Repository: http://cdr.eurolisp.org Closer to MOP & ContextL: http://common-lisp.net/project/closer/
From: Madhu on 14 Oct 2009 18:11 * Pascal Costanza <7jmvurF34o6uiU1(a)mid.individual.net> : Wrote on Wed, 14 Oct 2009 23:59:55 +0200: | Madhu wrote: |> * 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. | | I find this very easy to believe. Such problems and the fact that they | are discovered only very late occur all the time when defining | languages or libraries. No, I maintain it is logically (in a ron-garett) sense impossible given the motivation and the item being defined. The more plausible explanation is that they thought about it and punted on it as there was a reasonable implementation. -- Madhu
From: Pascal Costanza on 14 Oct 2009 18:28 Madhu wrote: > * Pascal Costanza <7jmvurF34o6uiU1(a)mid.individual.net> : > Wrote on Wed, 14 Oct 2009 23:59:55 +0200: > > | Madhu wrote: > |> * 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. > | > | I find this very easy to believe. Such problems and the fact that they > | are discovered only very late occur all the time when defining > | languages or libraries. > > No, I maintain it is logically (in a ron-garett) sense impossible given > the motivation and the item being defined. > > The more plausible explanation is that they thought about it and punted > on it as there was a reasonable implementation. This assumes they had infinite time to think about each and every potential decision they had to made. That's a very strong, and very unlikely assumption. Heck, they got prog2 wrong. ;) This issue being discussed here is much less likely to stumble over... Pascal -- My website: http://p-cos.net Common Lisp Document Repository: http://cdr.eurolisp.org Closer to MOP & ContextL: http://common-lisp.net/project/closer/
From: Madhu on 14 Oct 2009 18:36 * Pascal Costanza <7jn1k2F36ppenU2(a)mid.individual.net> : Wrote on Thu, 15 Oct 2009 00:28:19 +0200: | This assumes they had infinite time to think about each and every | potential decision they had to made. That's a very strong, and very | unlikely assumption. No, this does not assume infinite time, I am not sure what you are arguing or if you are just avoiding my point. The internal evidence is all I am basing my statement on. The claim that the thought X did not occur at all can only be a convenient after the fact fiction after the thought X did in fact occur, given that X was the precisely thought on the mind at the time of proceedings. -- Madhu
From: Pascal Costanza on 14 Oct 2009 19:18
Madhu wrote: > * Pascal Costanza <7jn1k2F36ppenU2(a)mid.individual.net> : > Wrote on Thu, 15 Oct 2009 00:28:19 +0200: > > | This assumes they had infinite time to think about each and every > | potential decision they had to made. That's a very strong, and very > | unlikely assumption. > > No, this does not assume infinite time, I am not sure what you are > arguing or if you are just avoiding my point. The internal evidence is > all I am basing my statement on. > > The claim that the thought X did not occur at all can only be a > convenient after the fact fiction after the thought X did in fact occur, > given that X was the precisely thought on the mind at the time of > proceedings. Whatever... Pascal -- My website: http://p-cos.net Common Lisp Document Repository: http://cdr.eurolisp.org Closer to MOP & ContextL: http://common-lisp.net/project/closer/ |