DEFSTRUCT and lexical environment
in [Lisp]
|
From: Madhu on 15 Oct 2009 21:31 * Tim Bradshaw <2009101519361950073-tfb(a)cleycom> : Wrote on Thu, 15 Oct 2009 19:36:19 +0100: | On 2009-10-15 05:57:24 +0100, Madhu <enometh(a)meer.net> said: | |> It is also of limited utility if you observe how the Common Lisp |> Specification for defstruct promises that the file compiler will |> recognize an earlier defstruct for Inclusion via INCLUDE only the |> earlier defstruct appeared as a toplevel form. | | This is incorrect. How so? I just paraphrased the following | "If a defstruct form appears as a top level form, the compiler must | make the structure type name recognized as a valid type name in | subsequent declarations (as for deftype) and make the structure slot | readers known to setf. In addition, the compiler must save enough | information about the structure type so that further defstruct | definitions can use :include in a subsequent deftype in the same file | to refer to the structure type name." | | In other words, this is talking about subsequent definitions in the | same file. Which is what I was talking about too--- In the context of a single file. which the PROGN in the example would have entailed. And as I clarified later in the thread when i said `if you put it in a file and compile' I was waiting for a suitable example to come up before I could make this point. Again I have to take offence. There is nothing you can misrepresent in these words, please refrain from trying to mischaracterise my points. -- Madhu
From: Madhu on 15 Oct 2009 21:33 [I can respond to you now you aren't using google groups] * Tim Bradshaw <2009101519190016807-tfb(a)cleycom> : Wrote on Thu, 15 Oct 2009 19:19:00 +0100: | On 2009-10-14 23:41:24 +0100, Madhu <enometh(a)meer.net> said: | |> 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. | | Gosh. And of course you are much better equipped to speak about this | than people who were actually there. Well, the internal evidence here suggests they may be lying through their teeth -- Madhu
From: netsettler on 15 Oct 2009 21:50 On Oct 15, 1:54 pm, Scott Burson <fset....(a)gmail.com> wrote: > On Oct 14, 4:59 am, bj...(a)runa.se (Björn Lindberg) wrote: > > > It would be interesting to have Kent Pitman's input on the subject. > > You already have Alan Bawden's input (see earlier in this thread), > which addresses your question very well. Though Alan doesn't post > here much, I assure you he is as highly regarded in the CL implementor > community as Kent. I second that endorsement of Alan's credentials. To my knowledge, he wasn't formally part of the CL process, but he has over the years also contributed to the MACLISP, Lisp Machine Lisp, Dylan, and Scheme communities, for example, and is indeed well-regarded throughout the community of designers and implementors. Personally, I've mostly contributed comments over the years to make sure that at least _someone_ did, so that we'd have an informed community. But CL was a group effort involving a quite amazing community of designers, implementors, and users, and to the extent others like Steve Haflich, Barry Margolin, Will Clinger, Dan Weinreb, Alan Bawden and others who followed its evolution have opinions (even ones that conflict directly with mine), you should pay careful attention. We each experienced it differently, we each remember (and forget) different things, and we each have our respective tales to tell and differing perspectives to offer. But yes, his specific remarks upthread [1] seem relevant and well- stated to me. --Kent [1] http://groups.google.com/group/comp.lang.lisp/msg/de6ef64bf5ce37b6
From: Madhu on 15 Oct 2009 21:50 [spellchecked version, in case spelling was important to tfb, I really do not wish to follow up as I believe all the points have been made] * Don Geddis <87pr8ofe4i.fsf(a)geddis.org> : Wrote on Thu, 15 Oct 2009 16:09:49 -0700: | I think your parenthetical comment is false: you underestimate the | ingenuity and stubborness of your fellow humans! :-) | | While any REASONABLE person would realize that's an obvious typo, | nonetheless these language lawyer arguments can get very bitter. And | the fact remains that the official ANSI spec has very clear language, | which requires a behavior that is violated by every CL implementation | that I know of. If you notice the issues in question, you will see you are making a false analogy with intent to mislead, and to portray me as stubborn and stupid follower of the word of the spec, ignoring its intentions. I resent that The question around defstruct remains because what the spec describes is how a DEFSTRUCT (FOO :INCLUDE BAR) constructs a MAKE-FOO (&KEY (SLOT1 SLOT1-INITFORM) (SLOT2 SLOT2-INITFORM)) form, which refers to the constructor for FOO. This is then compiled in the lexical context of the defstruct macro. This is the conceptual model based (I believe on Alan Bawden's implementation). Note macros in lisp are not hygienic. It is reasonable in the context of Common Lisp to assume that the lexical context in which this entire form is assembled and compiled is in the _lexical context_ of this macro. Alan Bawden's original implementation (which the Specification is based on) is a sound implementation of this model. He even says that the present discussion of lexical environment is only a result of wording introduced when the Committee tried to clean up the issue of lexical environments from hygiene considerations (though they reportedly deny it even occurred to them how lexical environments interacted with defstruct includes, which I have charitably said, is hard to believe). However the Specification also simultaneously renders the question moot by not requiring anything but top-level forms to be included by the compiler in a single file. So to be "useful". the defstruct has to be a toplevel form, without a lexical environment. This (if you believe the cleanup issue on toplevel forms) is from defmacro considerations. The model and implementation of defstruct as it stands is `reasonable' given other parts of CL including an unhygienic macro system, and does not violate referential transparency as is claimed: There is a point of view in which referential transparency is not violated. Consider an initform is a fragment of code with free variables. (MAKE-FOO &key (id (incf counter))), the COUNTER is a free variable which is bound in the lexical context of MAKE-FOO. (let ((counter 0)) (defstruct foo (id counter))) ; counter for foos, (let ((counter 0)) (defstruct (bar (:include foo)))) ; counter for bars The spec describes how a (MAKE-BAR (&key (id (incf counter)))) is built up. This would refer to a form with a free variable COUNTER which is bound in the lexical context of the MAKE-BAR, not MAKE-FOO. This is abhorrent, yes, maybe. But only unreasonable if you have have been catechised in the doctrine of hygiene in the context of scheme, All the emotional appeals against this refer to "THE CORRECT THING" and "THE RIGHT WAY" Which is why I started off the thread saying this is an ideal personality test for scheme braindamage The point is this is not just a clerical error in the Specification as the those appealing to `reasonable' and `correct' would have you believe. -- Madhu
From: Alan Bawden on 16 Oct 2009 01:21
Madhu <enometh(a)meer.net> writes: > ... > Alan Bawden's original implementation (which the Specification is based > on) is a sound implementation of this model... I believe you are misinterpreting what I said. My original implementation was not a sound implementation of -any- interpretation of the current specification. It was even more broken than the broken interpretation you seem to favor. My point was that the committee was clearly aiming to -fix- the problem with initform scope, and certainly intended to fix it completely -- not halfway. |