DEFSTRUCT and lexical environment
in [Lisp]
|
From: Ron Garret on 16 Oct 2009 03:14 In article <m3aazsjedg.fsf(a)moon.robolove.meer.net>, Madhu <enometh(a)meer.net> wrote: > [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 If the shoe fits... The problem with DEFSTRUCT is just as obvious as the problem with PROG2. And everyone is apparently able to see it except you (and maybe Kenny). > 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). No, that is not what the spec describes. That is ONE POSSIBLE INTERPRETATION of what the spec describes. The spec is AMBIGUOUS. > Note macros in lisp are not hygienic. That's right. But this is widely recognized to be a problem, not a feature. That problem is solved in CL by making it a Lisp2 and adding packages. But solving a problem doesn't mean it wasn't a problem. > 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. It is reasonable to suppose that this is one interpretation. It is not reasonable to suppose that this is the only possible interpretation, which is the position you were taking. Even now you are trying to defend it as a good design. It isn't. Even the person who originated it says so. > Alan Bawden's original implementation (which the Specification is based > on) is a sound implementation of this model. So Alan once produced a sound implementation of a bad design. And your point would be...? rg
From: Tamas K Papp on 16 Oct 2009 03:26 On Thu, 15 Oct 2009 16:09:49 -0700, Don Geddis wrote: > 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. Talking of lawyers (and other participants of the legal system): they have developed ways of coping with ambiguity in laws. When encountering ambiguity, one possibility is to try to reconstruct "the intent of the lawmaker". [1] So I think that whenever we encounter an ambiguity or a typo in the standard, it would be good to argue for what fits best into the logic of the rest of CL, then write up a CDR about it and settle the issue. Tamas [1] http://en.wikipedia.org/wiki/Judicial_interpretation
From: Madhu on 16 Oct 2009 03:26 * Alan Bawden <w2d7huvykv4.fsf(a)shaggy.csail.mit.edu> : Wrote on 16 Oct 2009 01:21:35 -0400: |> ... |> 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. OK! I stand humbled :) I am not really in favour of the "broken interpretation", but also believe the "broken interpretation" is consistent with the model which the defstruct specification describes: that of creating a constructor where the initform FORM becomes the default VALUE of the keyword argument. I interpreted your earlier post as stating that this model, of how defstruct behaves, originated in your implementation. The "broken interpretation" also seems (to me) to be consistent with how defmacro is defined to behave were it to be used in implementing such a model. -- Madhu
From: Madhu on 16 Oct 2009 03:28 * Tamas K Papp <7jqli2F36hlf6U1(a)mid.individual.net> : Wrote on 16 Oct 2009 07:26:58 GMT: | Talking of lawyers (and other participants of the legal system): they | have developed ways of coping with ambiguity in laws. When | encountering ambiguity, one possibility is to try to reconstruct "the | intent of the lawmaker". [1] So I think that whenever we encounter an | ambiguity or a typo in the standard, it would be good to argue for | what fits best into the logic of the rest of CL, then write up a CDR | about it and settle the issue. Judging by the show of hands on this issue, it looks like the `next CL' will lack dual namespaces, have no defmacro, have a READer which works on text strings, etc., as these are all obvious bugs in the CL specification which would need to be fixed. -- Madhu
From: Tamas K Papp on 16 Oct 2009 03:41
On Fri, 16 Oct 2009 12:58:53 +0530, Madhu wrote: > * Tamas K Papp <7jqli2F36hlf6U1(a)mid.individual.net> : Wrote on 16 Oct > 2009 07:26:58 GMT: > > | Talking of lawyers (and other participants of the legal system): they > | have developed ways of coping with ambiguity in laws. When | > encountering ambiguity, one possibility is to try to reconstruct "the | > intent of the lawmaker". [1] So I think that whenever we encounter an | > ambiguity or a typo in the standard, it would be good to argue for | > what fits best into the logic of the rest of CL, then write up a CDR | > about it and settle the issue. > > Judging by the show of hands on this issue, it looks like the `next CL' > will lack dual namespaces, have no defmacro, have a READer which works > on text strings, etc., as these are all obvious bugs in the CL > specification which would need to be fixed. Perhaps you are reading some other forum? I don't really get that impression. Besides, I was talking about fixing ambiguities in the standard. How do, for example, dual namespaces and macros count as ambiguous? Tamas |