DEFSTRUCT and lexical environment
in [Lisp]
|
From: Tim Bradshaw on 15 Oct 2009 14:36 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. Although the standard clearly has another bug here, the text is: "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. (The bug is that the last DEFTYPE should be DEFSTRUCT.)
From: Tim Bradshaw on 15 Oct 2009 14:39 On 2009-10-15 19:32:59 +0100, Tamas K Papp <tkpapp(a)gmail.com> said: > Oh, I see, thanks. But it is pretty clear that this is an > unintented mistake, and there is no ambiguity (no one would > seriously suggest that (prog2 1 2 3) => 2 is non-conforming). Absolutely so. But it's pretty clear to almost everyone I think that the ambiguity around DEFSTRUCT is also an unintended mistake.
From: Thomas A. Russ on 15 Oct 2009 18:48 Vassil Nikolov <vnikolov(a)pobox.com> writes: > I don't know what the cost to implementors would be to change the > respective DEFSTRUCT implementations to fully capture the lexical > environment at the point of definition (rather than the point of > inclusion). In any case, this is a matter of low severity... Well, the only part of it that gets you in trouble is that you have to KNOW about the lexical variable part whenever you decide to include that structure. That's because (let ((x 6)) (defstruct foo (s x))) (defstruct (bar (:include foo))) (make-bar) leads to an unbound variable error. -- Thomas A. Russ, USC/Information Sciences Institute
From: Don Geddis on 15 Oct 2009 19:09 Tamas K Papp <tkpapp(a)gmail.com> wrote on 15 Oct 2009 18:3: > On Thu, 15 Oct 2009 19:20:30 +0100, Tim Bradshaw wrote: >> On 2009-10-15 08:41:53 +0100, Tamas K Papp <tkpapp(a)gmail.com> said: >>> How is prog2 wrong? > But it is pretty clear that this is an unintented mistake, and there is no > ambiguity (no one would seriously suggest that (prog2 1 2 3) => 2 is > non-conforming). 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. Alas, people are not always reasonable. _______________________________________________________________________________ Don Geddis http://don.geddis.org/ don(a)geddis.org No computer has ever been designed that is ever aware of what it's doing; but most of the time, we aren't either. -- Marvin Minsky
From: Madhu on 15 Oct 2009 21:12
* 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 hygeneic. 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 occured to them how lexical environments interacted with defstruct includes, which I have charitably said, is hard to believe). However the Specification also simaltaneously 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 unhygenic 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 the 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 |