DEFSTRUCT and lexical environment
in [Lisp]
|
From: Ron Garret on 14 Oct 2009 04:56 In article <7jlb1mF3629epU1(a)mid.individual.net>, Tamas K Papp <tkpapp(a)gmail.com> wrote: > On Tue, 13 Oct 2009 21:33:30 -0700, Ron Garret wrote: > > > to you, but CLL is not the center of the universe. It is not even the > > center of the Lisp universe. > > A question tangential to this thread: what other centers are there? Most Lisp discussions outside of CLL happens (AFAIK) on the development lists for the various implementations. The exchange involving Dan Weinreb happened on the CCL list (which, for historical reasons, is called openmcl-devel). > Is there any other general CL forum? Not that I'm aware of. rg
From: Ron Garret on 14 Oct 2009 05:18 In article <m3eip6v3pp.fsf(a)moon.robolove.meer.net>, Madhu <enometh(a)meer.net> wrote: [Irrelevant bullshit elided] > Your argument is based your personal expectations, and any "additional > evidence" which you _allege_ Weinreb has supplied can at best be his > personal opinion. That's true, but Dan Weinreb's is not just anyone. Dan was a member of the ANSI CL committee. As such, on questions of history regarding the development of the spec, Dan is a primary source. Just for the record, here's what Dan actually said: "I think I can say pretty reliably that during the design of CL, nobody thought about this. So the spec is not written in such a way as to give unambiguous guidance about what these forms ought to do." If you want the complete context, you can look it up on the openmcl-devel list. > The Specification itself has seen common lisp implementations which have > apparently confounded your expectation. No, that's not true. Because my position is that the spec is ambiguous, my expectation is that some implementations would do it one way, and some would do it the other way. Which is in fact exactly what we observe. > I can say they have not confounded mine Not so. CLisp confounds your expectations. You're just not willing to admit it, so you simply label CLisp as "buggy". You are the CL equivalent of a young-earth Creationist. Any evidence opposing your position you merely dismiss as buggy or inaccurate (despite all evidence to the contrary) or as the product of some political agenda. > and the behaviour in fact conforms with what I have > come to expect, given the spirit expressed in other parts of the > language [which I do not assume you have any familiarity or sympathy > with] You assume incorrectly. And you do so again and again and again. rg
From: Pascal J. Bourguignon on 14 Oct 2009 05:18 Ron Garret <rNOSPAMon(a)flownet.com> writes: > In article <7jlb1mF3629epU1(a)mid.individual.net>, > Tamas K Papp <tkpapp(a)gmail.com> wrote: > >> On Tue, 13 Oct 2009 21:33:30 -0700, Ron Garret wrote: >> >> > to you, but CLL is not the center of the universe. It is not even the >> > center of the Lisp universe. >> >> A question tangential to this thread: what other centers are there? > > Most Lisp discussions outside of CLL happens (AFAIK) on the development > lists for the various implementations. The exchange involving Dan > Weinreb happened on the CCL list (which, for historical reasons, is > called openmcl-devel). > >> Is there any other general CL forum? > > Not that I'm aware of. There's a couple of national cll, such as fr.comp.lang.lisp, but admitedly, with much less traffic that would be healthy. There's some lisp web forum. various irc channels, etc. -- __Pascal Bourguignon__
From: Madhu on 14 Oct 2009 05:47 * Ron Garret <rNOSPAMon-F3808B.02181614102009(a)news.albasani.net> : Wrote on Wed, 14 Oct 2009 02:18:16 -0700: | In article <m3eip6v3pp.fsf(a)moon.robolove.meer.net>, | Madhu <enometh(a)meer.net> wrote: | | [Irrelevant bullshit elided] That was the basic point. I will not respond to you in this thread again, but I am making a defence of the CL spec below. |> Your argument is based your personal expectations, and any "additional |> evidence" which you _allege_ Weinreb has supplied can at best be his |> personal opinion. | | That's true, but Dan Weinreb's is not just anyone. Dan was a member | of the ANSI CL committee. As such, on questions of history regarding | the development of the spec, Dan is a primary source. | | Just for the record, here's what Dan actually said: | | "I think I can say pretty reliably | that during the design of CL, nobody thought about | this. So the spec is not written in such a way as to | give unambiguous guidance about what these forms | ought to do." I believe he means "He" did not think about this. [broken record plays again] | |> and the behaviour in fact conforms with what I have |> come to expect, given the spirit expressed in other parts of the |> language [which I do not assume you have any familiarity or sympathy |> with] ^^ familiarity with or sympathy for | You assume incorrectly. And you do so again and again and again. Others may wish to consider that in CL, DEFSTRUCT is a defined as a macro. When I do C-Shift-m Macroexpand-1 around a defstruct definition I expect to see the entire form for THAT defstruct definition, which will be evaluated in the lexical environment of that Defstruct form. As a CL programmer I am not accustomed to seeing opaque undebuggable closures when I do this. Instead I expect to see the entire form of the defstruct which :includes (as defined in the specification) the literal forms of the included defstruct definition, as the specification indicates, So I know EXACTLY (by the principles of referential transparency) what is evaluated in the one lexical environment (of the macro) of the defstruct. This is the rationale for my claim that a possible ambiguity has been resolved, in the context of the CL language. The alternative interpretation does not make sense in this context. The scheme indoctrinated will find this sort of power too much to handle. However there is more hope in the more people will be discovering the lisp way now that MIT has officially stopped indoctrinating its freshmen. [I couldnt resist the flamebait, but I promise not to reel in] -- Madhu
From: =?iso-8859-1?Q?Bj=F6rn?= Lindberg on 14 Oct 2009 06:08
Kaz Kylheku <kkylheku(a)gmail.com> writes: > 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. > 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. You are mistaken. The Hyperspec glossary has this to say: initialization form n. a form used to supply the initial value for a slot or variable. ``The initialization form for a slot in a defclass form is introduced by the keyword :initform.'' There is no mention of in which lexical environment initforms *in general* are evaluated. The entry on defclass makes it explicit for defclass slot initforms, which does not pertain to those of defstruct. > 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. Which are evaluated in the lexical environment of the lambda. A form in a lambda is more than just a form. In any case, one passage in the Hyperspec which hasn't been mentioned yet is the following: It is as if the slot-initforms were used as initialization forms for the keyword parameters of the constructor function. If it is relevant to the case at hand, it implies the interpretation where initforms are evaluated in the lexical envvironment of the *including* structure definition. Bj�rn Lindberg |