DEFSTRUCT and lexical environment
in [Lisp]
|
From: Scott Burson on 12 Oct 2009 12:14 On Oct 12, 3:13 am, Madhu <enom...(a)meer.net> wrote: > Every description related to the slot-initforms indicates they are FORMS > inserted into the description of the structure being defined. Not some > funcallable closure. For example > > ,---- > | The structure using :include can specify default values or > | slot-options for the included slots different from those the included > | structure specifies, by giving the :include option as: > | > | (:include included-structure-name slot-description*) > | > | Each slot-description must have a slot-name that is the same as that > | of some slot in the included structure. If a slot-description has no > | slot-initform, then in the new structure the slot has no initial > | value. Otherwise its initial value form is replaced by the > | slot-initform in the slot-description. Yeah, I see this passage too. In my opinion, the committee didn't quite finish working out the consequences of the requirement that the initforms be evaluated in the lexical context of "the defstruct form" in the case when :INCLUDE is involved. You are welcome to your own opinion. I will not dignify your gratuitous insult with a reply. -- Scott
From: Vassil Nikolov on 12 Oct 2009 21:29 On Mon, 12 Oct 2009 15:43:15 +0530, Madhu <enometh(a)meer.net> said: > ... > Every description related to the slot-initforms indicates they are FORMS > inserted into the description of the structure being defined. Not some > funcallable closure. 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. * * * As it happens, "Brain Damage" has been taken by another thread, but I am more partial to "λ-surgeons screaming for more" anyway (for almost exactly 40 years now [*])... _________ [*] taking the liberty to distort ν-ρ-surgeons a little... ---Vassil. -- "Even when the muse is posting on Usenet, Alexander Sergeevich?"
From: Ron Garret on 13 Oct 2009 03:02 In article <m31vl8x6mc.fsf(a)moon.robolove.meer.net>, Madhu <enometh(a)meer.net> wrote: > * Vassil Nikolov <snzy6nh2mbg.fsf(a)luna.vassil.nikolov.name> : > Wrote on Mon, 12 Oct 2009 01:49:55 -0400: > > | On Sun, 11 Oct 2009 22:14:59 -0700 (PDT), Scott Burson > | <fset.slb(a)gmail.com> said: > |> ... > |> Unfortunately, none of the three implementations > |> I just tried (Allegro, LispWorks, and CMUCL) agree with us. > | > | CLISP, though: > > This is as usual a non-conforming bug in CLISP Says you. > Every description related to the slot-initforms indicates they are FORMS > inserted into the description of the structure being defined. Not some > funcallable closure. No, that is not true. The very fact that a lexical environment is mentioned indicates that these are not just forms, that there are in fact (or at least should be) closures being created behind the scenes. > For example A universally quantified claim cannot be proven with examples. > I believe any alleged ambiguity in the spec is amply resolved in the > remaining wording. Just because you are blind to the ambiguity does not mean it isn't there. > However instead of wringing hands at misplaced > newbie-expectations This has nothing to do with newbie expectations. This has to do with the fact that your interpretation would be a BAD DESIGN because it would break the referential opacity of included structures. rg
From: Madhu on 13 Oct 2009 08:06 * Ron Garret Wrote on Tue, 13 Oct 2009 00:02:19 -0700: | |> I believe any alleged ambiguity in the spec is amply resolved in the |> remaining wording. | | Just because you are blind to the ambiguity does not mean it isn't | there. Just because you keep pointing out potential for ambiguity doesnt mean that it has not been resolved. | |> However instead of wringing hands at misplaced |> newbie-expectations | | This has nothing to do with newbie expectations. Says you. Once the newbie is emancipated, where will you be? -- Madhu
From: Kaz Kylheku on 13 Oct 2009 13:43
On 2009-10-12, Madhu <enometh(a)meer.net> wrote: > > * Vassil Nikolov <snzy6nh2mbg.fsf(a)luna.vassil.nikolov.name> : > Wrote on Mon, 12 Oct 2009 01:49:55 -0400: > >| On Sun, 11 Oct 2009 22:14:59 -0700 (PDT), Scott Burson >| <fset.slb(a)gmail.com> said: >|> ... >|> Unfortunately, none of the three implementations >|> I just tried (Allegro, LispWorks, and CMUCL) agree with us. >| >| CLISP, though: > > This is as usual a non-conforming bug in CLISP, I wouldnt be surprised > if SBCL also took a similar implementation. > > Every description related to the slot-initforms indicates they are FORMS > inserted into the description of the structure being defined. Not some > funcallable closure. Idiot, there is no conflict there. Something can be a form, /and/ it can be wrapped in a funcallable closure (for lexical transparency). Initforms are understood to be evaluated in their original lexical environment, not in the environment where the constructor is being called. This is not only true for DEFSTRUCT but also for DEFCLASS. A form is an ``any object meant to be evaluated'', not ``any object meant to be evaluated in the lexical environment of the point where the evaluation is invoked''. The body of a lambda, if not empty, consists of what? Forms. |