DEFSTRUCT and lexical environment
Jerry Boetje
that is silent on the lexical environment of the included struct.
Here's an example:
Start with
(let ((x 99)) (defstruct foo (a (+ x 2))))
Making a FOO yields
#S(FOO :A 101) ;; as you expect
But if now we make BAR that includes FOO, what happens to the closure?
(defstruct (bar (:include foo)) (b 2))
If I make a BAR, is the result of (make-bar)
#S(BAR :A 101 :B 2)
or
#S(BAR :A NIL :B 2)
or something else...
To make it interesting, define BAR as
(let ((x 42)) (defstruct (bar (:include foo)) (b 2)))
(make-bar) =>
#S(BAR :A 42 :B 2)
or
#S(BAR :A 101 :B 2)
Thoughts?
Vassil Nikolov
On Fri, 9 Oct 2009 10:59:48 -0700 (PDT), Jerry Boetje <jerry...@mac.com> said:
> While working on the :include option, I came across a part of the spec
> that is silent on the lexical environment of the included struct.
I would interpret
:INCLUDE causes the structure being defined to have the same slots
as the included structure.
to imply sameness of the initforms as well (including preservation
of their lexical environments), rather than a sort of a "macro
expansion" of the included structure definition at the place of
inclusion. I would also argue that the former is the natural
meaning of this kind of inclusion.
---Vassil.
--
"Even when the muse is posting on Usenet, Alexander Sergeevich?"
Madhu
* Vassil Nikolov <snzbpkf...@luna.vassil.nikolov.name> :
Wrote on Fri, 09 Oct 2009 23:51:47 -0400:
| On Fri, 9 Oct 2009 10:59:48 -0700 (PDT), Jerry Boetje said:
|
|> While working on the :include option, I came across a part of the spec
|> that is silent on the lexical environment of the included struct.
|
| I would interpret
|
| :INCLUDE causes the structure being defined to have the same slots
| as the included structure.
|
| to imply sameness of the initforms as well (including preservation
| of their lexical environments), rather than a sort of a "macro
| expansion" of the included structure definition at the place of
| inclusion. I would also argue that the former is the natural
| meaning of this kind of inclusion.
I do not think this interpretation is valid. Because the specification
of DEFSTRUCT specifically says
,----
| The slot default init forms are evaluated in the lexical
| environment in which the defstruct form itself appears and in the
| dynamic environment in which the call to the constructor function
| appears.
|
| For example, if the form (gensym) were used as an initialization form,
| either in the constructor-function call or as the default
| initialization form in defstruct, then every call to the constructor
| function would call gensym once to generate a new symbol.
`----
The first para would indicate ``a sort of a "macro expansion" of the
included structure definition at the place'' that you mentioned is
indeed required.
(unintern 'x)
(let ((x 99)) (defstruct foo (a (+ x 2))))
(make-foo) ; evaluates the initform (+ x 2) in the lexical environment of the
; (defstruct foo) form
(defstruct (bar (:include foo)) (b 2))
(make-bar) ; evaluates initform (+ x 2) in the lexical environment of the
; (defstruct bar) form.
; => _Should_ signal ERROR: UNBOUND VARIABLE X
(let ((x 20)) (make-bar)) ; same as above, lexical env of the call to
; make-bar does not affect the initform
(let ((x 20)) (declare (special x)) (make-bar))
;; => #S(BAR :A 22 :B 2) ; the initform (+ x 2) is evaluated in the
; dynamical environment of the call to
; MAKE-BAR
--
Madhu
Ron Garret
Madhu <eno...@meer.net> wrote:
> * Vassil Nikolov <snzbpkf...@luna.vassil.nikolov.name> :
> Wrote on Fri, 09 Oct 2009 23:51:47 -0400:
>
> | On Fri, 9 Oct 2009 10:59:48 -0700 (PDT), Jerry Boetje said:
> |
> |> While working on the :include option, I came across a part of the spec
> |> that is silent on the lexical environment of the included struct.
> |
> | I would interpret
> |
> | :INCLUDE causes the structure being defined to have the same slots
> | as the included structure.
> |
> | to imply sameness of the initforms as well (including preservation
> | of their lexical environments), rather than a sort of a "macro
> | expansion" of the included structure definition at the place of
> | inclusion. I would also argue that the former is the natural
> | meaning of this kind of inclusion.
>
> I do not think this interpretation is valid. Because the specification
> of DEFSTRUCT specifically says
>
> ,----
> | The slot default init forms are evaluated in the lexical
> | environment in which the defstruct form itself appears
The antecedent of "the defstruct form itself" is ambiguous. It could
refer to either the included or the including defstruct. Personally I
think the former makes more sense, otherwise you pervert the usual
meaning of the word "lexical".
rg
Madhu
* Ron Garret <rNOSPAMon-6DA09...@news.albasani.net> :
Wrote on Sat, 10 Oct 2009 02:08:56 -0700:
|> ,----
|> | The slot default init forms are evaluated in the lexical
|> | environment in which the defstruct form itself appears
|
| The antecedent of "the defstruct form itself" is ambiguous. It could
| refer to either the included or the including defstruct. Personally I
| think the former makes more sense, otherwise you pervert the usual
| meaning of the word "lexical".
The usually meaning of the word "lexical" is expressly not perverted,
because it refers to the lexical environment of the defstruct form being
defined. There is only ONE (1) lexical environment at the point of
definition of the DEFSTRUCT form in question, and there is no ambiguity
which defstruct form is, because it is the one you are talking about.
I think you are introducing ambiguity where there is none.
There is no confusion in the spec as far as I can see, and I think my
examples ought to have clarified that.
I fear again you are simply exploiting possible misunderstandings and
confusions of humans (who are naturally falliable) and pandering to the
resulting emotions. :)
--
Madhu
JB at CofC
> * Ron Garret <rNOSPAMon-6DA09F.02085410102...@news.albasani.net> :
I am inclined to go with an interpretation that the INIT form in FOO
is forever linked to the lexical environment at the point of (let ((x
22)) (defstruct... and carries through an inclusion in BAR regardless
of the lexical environment of BAR. It seems more logical to use the
full form of :INCLUDE to redefine X. Then it's clear what's happening.
For example
(let ((x 40)) (defstruct (bar (:include foo (a :init-form (+ x
17)))) (b 20)))
Looking at that form, it seems that's the correct interpretation and
solution.
Ron Garret
Madhu <eno...@meer.net> wrote:
> * Ron Garret <rNOSPAMon-6DA09...@news.albasani.net> :
> Wrote on Sat, 10 Oct 2009 02:08:56 -0700:
>
> |> ,----
> |> | The slot default init forms are evaluated in the lexical
> |> | environment in which the defstruct form itself appears
> |
> | The antecedent of "the defstruct form itself" is ambiguous. It could
> | refer to either the included or the including defstruct. Personally I
> | think the former makes more sense, otherwise you pervert the usual
> | meaning of the word "lexical".
>
> The usually meaning of the word "lexical" is expressly not perverted,
> because it refers to the lexical environment of the defstruct form being
> defined. There is only ONE (1) lexical environment at the point of
> definition of the DEFSTRUCT form in question
No. If you have an :include option then there are two defstruct forms
in question, the one being defined and the :included one, and hence two
lexical environments potentially in play.
Reasonable people could certainly disagree, but IMHO the following
behavior is undesirable:
? (defstruct (baz (:include foo)))
;Compiler warnings :
; In MAKE-BAZ: Undeclared free variable X
X? What X? I don't see any X. Do you see an X?
This is even worse IMHO:
? (make-baz)
Error: Unbound variable: X
And this is worse still:
? (defvar x 'some-random-value)
X
? (make-baz)
#S(BAZ :Z SOME-RANDOM-VALUE)
?
Note that the slot that gets initialized to some-random-value is named
Z, not X.
And if that's not bad enough, here's the capper:
? (make-baz)
Error: value SOME-RANDOM-VALUE is not of the expected type NUMBER.
> I think you are introducing ambiguity where there is none.
No, I am pointing out ambiguity where it actually exists.
> There is no confusion in the spec as far as I can see, and I think my
> examples ought to have clarified that.
It is logically impossible to prove the absence of ambiguity with
examples.
> I fear again you are simply exploiting possible misunderstandings and
> confusions
Are you a native English speaker? What do you think the word
"ambiguity" means?
rg
JB at CofC
> In article <m3iqeno90s....@moon.robolove.meer.net>,
Here are some examples of what I think should be the correct behaviors
from my last post... BTW, they all assume that there are no special
variables
1. The one everyone agrees on...
(let ((x 40)) (defstruct foo (a (+ x 2))))
(make-foo)
=> #S(FOO :A 42)
..> this is true wherever the call to MAKE-FOO happens
2. The second where it gets interesting...
(defstruct (bar :include foo) (b 1))
(make-bar)
=> #S(BAR :A 42 :B 1)
3. (let ((x 20)) (defstruct (bar (:include foo)) (b 1)))
(make-bar)
=> #S(BAR :A 42 :B 1)
...> The binding of X occurred within the lexical environment in (1).
The binding of X in this example is irrelevant.
4. (let ((x 20))
(defstruct (bar (:include foo (a :init-form (+ x 10)))) (b 1)))
(make-bar)
=> #S(BAR :A 30 :B 1)
...> In this case, the :include clause redefines the init-form for
slot A.
...Now, here's another twist. What do you get when you try...
Obviously (bar-a (make-bar)) yields 30
But what happens if...
(foo-a (make-bar)) ;; is it 30 or 42?
Vassil Nikolov
On Sat, 10 Oct 2009 09:23:03 -0700 (PDT), JB at CofC <boe...@gmail.com> said:
> ...
> (let ((x 40)) (defstruct foo (a (+ x 2))))
> 4. (let ((x 20))
> (defstruct (bar (:include foo (a :init-form (+ x 10)))) (b 1)))
> ...Now, here's another twist. What do you get when you try...
> Obviously (bar-a (make-bar)) yields 30
> But what happens if...
> (foo-a (make-bar)) ;; is it 30 or 42?
Different initform in BAR, but still the same slot (and having two
slots with the same name is not allowed anyway), so, 30 for both.
JB at CofC
Good point. However, what if...
(let ((x 40)) (defstruct foo (a (+ x 2)))
(make-foo) => #S(FOO :A 42)
(foo-a ) => 42
If I make
(let ((x 50)) (defstruct (zorch (:include foo)) (b 5)))
and
(make-zorch) =>#S(ZORCH :A 42 :B 5) ;; the binding of X remains
(foo-a *) => 42
Now, if we use...
(let ((x 20)) (defstruct (bar (:include foo (a :init-form (+ x 10))))
(b 2)))
(make-bar) => #S(BAR :A 30 :B 2) ;; feels right
(foo-a *) => 30
From your interpretation, if I now add
(let ((x 'quux)) (defstruct (quux (:include foo :init-form x) (b 2)))
(make-quux) => #S(QUUX :A QUUX :B 2)
(foo-a *) => QUUX
Jerry
That feels right. Thanks for all help!
Madhu
* Ron Garret <rNOSPAMon-CEF6E...@news.albasani.net> :
Wrote on Sat, 10 Oct 2009 08:04:09 -0700:
| Are you a native English speaker? What do you think the word
| "ambiguity" means?
In an earlier thread you questioned if I understood the meaning of
`subversive when I applied it to what you were doing here, and you
suggested I look it up in a dictionary. I would suggest you do the same
thing, except I do not believe you are indulging in these discussion of
semantics for any worthwhile reason.
--
Madhu
Ron Garret
Madhu <eno...@meer.net> wrote:
> * Ron Garret <rNOSPAMon-CEF6E...@news.albasani.net> :
> Wrote on Sat, 10 Oct 2009 08:04:09 -0700:
>
> | Are you a native English speaker? What do you think the word
> | "ambiguity" means?
>
> In an earlier thread you questioned if I understood the meaning of
> `subversive
Indeed. At this point I am beginning to question if you understand
anything at all.
rg
Scott Burson
> In article <m3iqeno90s....@moon.robolove.meer.net>,
>
>
>
> > * Ron Garret <rNOSPAMon-6DA09F.02085410102...@news.albasani.net> :
I agree completely. Unfortunately, none of the three implementations
I just tried (Allegro, LispWorks, and CMUCL) agree with us.
-- Scott
Vassil Nikolov
On Sun, 11 Oct 2009 22:14:59 -0700 (PDT), Scott Burson <fset...@gmail.com> said:
> ...
> Unfortunately, none of the three implementations
> I just tried (Allegro, LispWorks, and CMUCL) agree with us.
CLISP, though:
[1]> (let ((x 1)) (defstruct foo (a x)))
FOO
[2]> (foo-a (make-foo))
1
[3]> (defstruct (bar (:include foo)))
BAR
[4]> (bar-a (make-bar))
1
[5]> (foo-a (make-bar))
1
[6]> (let ((x 2)) (declare (special x)) (bar-a (make-bar)))
1
[7]> (let ((x 2)) (defstruct (baz (:include foo))))
BAZ
[8]> (foo-a (make-baz))
1
Madhu
* Vassil Nikolov <snzy6nh...@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...@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. 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. A normally writable slot can be
| made read-only.
`----
I believe any alleged ambiguity in the spec is amply resolved in the
remaining wording. However instead of wringing hands at misplaced
newbie-expectations, , I think I should welcome this oppportunity as
another personality test to mark and take a census of all the scheme
braindamaged denizens of comp.lang.lisp
--
Madhu
Scott Burson
> 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
Vassil Nikolov
On Mon, 12 Oct 2009 15:43:15 +0530, Madhu <eno...@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...
Ron Garret
Madhu <eno...@meer.net> wrote:
> * Vassil Nikolov <snzy6nh...@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...@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
Madhu
* 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 emanciated, where will you be?
--
Madhu
Madhu
* Ron Garret Wrote on Tue, 13 Oct 2009 00:02:19 -0700:
|
|> 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
Kaz Kylheku
>
> * Vassil Nikolov <snzy6nh...@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...@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.
Kenneth Tilton
> Idiot, there is no conflict there. Something can be a form, /and/ it can be
> wrapped in a funcallable closure (for lexical transparency).
Ah, sweet reminder of the halcyon days of c.l.l!
kt
--
http://thelaughingstockatpngs.com/
http://www.facebook.com/pages/The-Laughingstock/115923141782?ref=nf
Ron Garret
Kaz Kylheku <kkyl...@gmail.com> wrote:
> On 2009-10-12, Madhu <eno...@meer.net> wrote:
> >
> > * Vassil Nikolov <snzy6nh...@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...@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).
Although I'm on your side in this debate, you are mistaken on two
counts. First, there is in fact a conflict because there are two
lexical environments in play when using the :include construct and the
spec does not specify which one is meant to be used. And second...
> Initforms are understood to be evaluated in their original lexical
> environment,
> not in the environment where the constructor is being called.
That is clearly not true. A majority of extant implementations do it
what you and I would consider the "wrong" way.
> This is not only true for DEFSTRUCT but also for DEFCLASS.
There is no :include construct for DEFCLASS (and hence no corresponding
ambiguous specification) so I don't see how this is relevant.
> 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''.
Again, this is not true. The body of a (non-hygienic) macro consists of
forms that are evaluated in a lexical environment other than the one in
which the macro is evaluated. (This is in fact the definition of
non-hygienic.) So Madhu's position, while wrong IMHO, is defensible.
BTW, Dan Weinreb, a member of the ANSI committee, weighed in on another
list where this topic was raised with the following:
"Regarding the former, 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."
rg
Ron Garret
Madhu <eno...@meer.net> wrote:
> * 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.
That is true. But when I claim that there is ambiguity I don't merely
ask you take my word for it, I offer arguments and evidence in support
of my position:
1. The structure of the English language. There are two possible
antecedents for the phrase "the lexical environment in which the
defstruct form appears" because there are two DEFSTRUCT forms in play.
That is the very definition of ambiguity.
2. The fact that different Lisp implementations implement this in
different ways.
3. The fact that experienced Lisp programmers, not just newbies (and
not just me), are disagreeing with you.
4. The fact that your interpretation of the spec violates the principle
of referential opacity of included structure definitions, which would
make it a bad design.
5. The fact that at least one member of the ANSI committee (Dan
Weinreb) has gone on the record to say that the spec is ambiguous.
Against this, you offer bogus arguments (all of which have so far been
debunked) and ad hominem attacks. So while your position might be
defensible (even though it's wrong), I have to say you aren't defending
it very well.
rg
Madhu
* Ron Garret <rNOSPAMon-45450...@news.albasani.net> :
Wrote on Tue, 13 Oct 2009 18:44:53 -0700:
|> Just because you keep pointing out potential for ambiguity doesnt mean
|> that it has not been resolved.
|
| That is true. But when I claim that there is ambiguity I don't merely
| ask you take my word for it, I offer arguments and evidence in support
| of my position:
|
| 1. The structure of the English language. There are two possible
| antecedents for the phrase "the lexical environment in which the
| defstruct form appears" because there are two DEFSTRUCT forms in play.
| That is the very definition of ambiguity.
There is however only one DEFSTRUCT form which is being defined, this
one includes the other. The resolution of the ambiguity is in realizing
that the lexical environment in question is this one.
| 2. The fact that different Lisp implementations implement this in
| different ways.
Thankfully!
| 5. The fact that at least one member of the ANSI committee (Dan
| Weinreb) has gone on the record to say that the spec is ambiguous.
I haven't seen Weinreb post on CLL, but it is clear where he stands on
the scheme personality test.
I also see Daniel Weinreb as a highly vested member of the community
(not necessarily for the good of Commom Lisp) and would advice people
take his recommendations with a modicum of salt.
--
Madhu
Ron Garret
Madhu <eno...@meer.net> wrote:
> * Ron Garret <rNOSPAMon-45450...@news.albasani.net> :
> Wrote on Tue, 13 Oct 2009 18:44:53 -0700:
>
> |> Just because you keep pointing out potential for ambiguity doesnt mean
> |> that it has not been resolved.
> |
> | That is true. But when I claim that there is ambiguity I don't merely
> | ask you take my word for it, I offer arguments and evidence in support
> | of my position:
> |
> | 1. The structure of the English language. There are two possible
> | antecedents for the phrase "the lexical environment in which the
> | defstruct form appears" because there are two DEFSTRUCT forms in play.
> | That is the very definition of ambiguity.
>
> There is however only one DEFSTRUCT form which is being defined, this
> one includes the other. The resolution of the ambiguity is in realizing
> that the lexical environment in question is this one.
But that's not evidence, that's simply restating your position using
different words. Look, I can use the exact same technique to make the
opposite argument:
"There is only one DEFSTRUCT form in which the initform appears.
Because of the meaning of the word "lexical" (i.e. being defined by the
structure of the code and not what happens at run-time), the "lexical
environment" in question must be this one."
Both your argument and this one are defensible. Hence the situation is,
by definition, ambiguous.
> | 2. The fact that different Lisp implementations implement this in
> | different ways.
>
> Thankfully!
Huh? Why "thankfully"? On your view, CLisp is buggy. That does not
seem to me like something you (or anyone else for that matter) ought to
be thankful for.
> | 5. The fact that at least one member of the ANSI committee (Dan
> | Weinreb) has gone on the record to say that the spec is ambiguous.
>
> I haven't seen Weinreb post on CLL
That's because Weinreb hasn't posted on CLL. This may come as a shock
to you, but CLL is not the center of the universe. It is not even the
center of the Lisp universe.
> but it is clear where he stands on the scheme personality test.
How fortunate for you that when defending an indefensible position one
can always fall back on ad hominem attacks. Otherwise you'd have
nothing left to say.
> I also see Daniel Weinreb as a highly vested member of the community
> (not necessarily for the good of Commom Lisp) and would advice people
> take his recommendations with a modicum of salt.
He wasn't making a recommendation, he was stating a historical fact.
You really do seem to have a lot of trouble with basic rhetorical
concepts.
rg
Madhu
* Ron Garret Wrote on Tue, 13 Oct 2009 21:33:30 -0700:
|
| How fortunate for you that when defending an indefensible position one
| can always fall back on ad hominem attacks. Otherwise you'd have
| nothing left to say.
|
|> I also see Daniel Weinreb as a highly vested member of the community
|> (not necessarily for the good of Commom Lisp) and would advice people
|> take his recommendations with a modicum of salt.
|
| He wasn't making a recommendation, he was stating a historical fact.
| You really do seem to have a lot of trouble with basic rhetorical
| concepts.
My interest in this thread is primarily in response to your despicable
style of dishonest rhetoric.
I have not said he made a recommendation in this case, because I have
not seen what he has said in this case. I said exactly what I meant,
not what you twisted it to mean.
This is the example of how you twist the spec so it meets your own
twisted expectations
--
Madhu
Ron Garret
Madhu <eno...@meer.net> wrote:
> * Ron Garret Wrote on Tue, 13 Oct 2009 21:33:30 -0700:
>
> |
> | How fortunate for you that when defending an indefensible position one
> | can always fall back on ad hominem attacks. Otherwise you'd have
> | nothing left to say.
> |
> |> I also see Daniel Weinreb as a highly vested member of the community
> |> (not necessarily for the good of Commom Lisp) and would advice people
> |> take his recommendations with a modicum of salt.
> |
> | He wasn't making a recommendation, he was stating a historical fact.
> | You really do seem to have a lot of trouble with basic rhetorical
> | concepts.
>
> My interest in this thread is primarily in response to your despicable
> style of dishonest rhetoric.
>
> I have not said he made a recommendation
Not explicitly, no. But you wrote that you "would advice [sic] people
to take [Dan Weinreb's] recommendations with a modicum of salt." Either
you meant to imply that Dan had made a recommendation or this is a
deliberate non-sequitur. Which is it?
> in this case, because I have
> not seen what he has said in this case. I said exactly what I meant,
> not what you twisted it to mean.
I did not twist it. I drew a reasonable inference based on what you
wrote and the assumption that you would not deliberately introduce a
non-sequitur in the conversation. But perhaps I was being too generous.
> This is the example of how you twist the spec so it meets your own
> twisted expectations
No, this is yet another example of your apparent lack of understanding
of English and the rules of logic and valid inference, to say nothing of
being yet another ad hominem.
There is ONLY ONE valid argument you can make to support your position,
and that is to show that my preferred interpretation of the spec is
invalid. If you can't do that (and you can't because it isn't) then the
situation is in fact, as I claim, ambiguous. Everything else, including
your own personal opinion and any recommendations Dan Weinreb may or may
not have made, is irrelevant. (Note that my introduction of what Dan
said was merely *additional evidence* in support of my position. So
even if you could completely discredit Dan that would not matter in the
least because my argument does not depend on Dan's views in any way.)
rg
Tamas K Papp
> 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?
Is there any other general CL forum? I am asking because I would be
interested in reading it.
Thanks,
Tamas
Madhu
Wrote on Tue, 13 Oct 2009 23:33:22 -0700:
|> I have not said he made a recommendation
|
| Not explicitly, no. But you wrote that you "would advice [sic] people
| to take [Dan Weinreb's] recommendations with a modicum of salt."
| Either you meant to imply that Dan had made a recommendation or this
| is a deliberate non-sequitur. Which is it?
I consider this is another exhibit of your dishonest style of twisting
the statement. I will let my statement stand, I cannot add anything to
make it clearer atop your feigned misunderstanding.
|> in this case, because I have not seen what he has said in this case.
|> I said exactly what I meant, not what you twisted it to mean.
|
| I did not twist it. I drew a reasonable inference based on what you
| wrote and the assumption that you would not deliberately introduce a
| non-sequitur in the conversation. But perhaps I was being too
| generous.
These are any number of unreasonable inferences you can draw and pass
off as reasonable. This is the point I wish to highlight.
|> This is the example of how you twist the spec so it meets your own
|> twisted expectations
|
| No, this is yet another example of your apparent lack of understanding
| of English and the rules of logic and valid inference, to say nothing
| of being yet another ad hominem.
This is another example of your style. There are any number of ways in
which to misunderstand a misunderstandable statement, given your skill
and [unstated] command of English, you believe you can exploit this and
misinterpret and mislead the audience by passing off your
[mis]interpretation as "reasonable."
My claim is it is "reasonable" only as long as you are uneducated about
the resolution of the potential conflict.
Even if the ambiguity has been resolved you could prefer to continually
ignore the fact, because you can continuallly state your [erraneous]
point of view as if the clarification never happened. [perhaps because
it hasn't happened to those who come across it for the first time]
[First Order] Logic and valid inference are tools which are not powerful
enough to expose such charlatanism. It is necessary to step outside the
formal framework to see what you are doing here.
| THERE is ONLY ONE valid argument you can make to support your
| position, and that is to show that my preferred interpretation of the
| spec is invalid. If you can't do that (and you can't because it
| isn't) then the situation is in fact, as I claim,
I believe your [mis]interpretation comes from misplaced expectations
from a different language, not one described by the Common Lisp
Specification.
| your own personal opinion and any recommendations Dan Weinreb may or
| may not have made, is irrelevant. (Note that my introduction of what
| Dan said was merely *additional evidence* in support of my position.
| So even if you could completely discredit Dan that would not matter in
| the least because my argument does not depend on Dan's views in any
| way.)
Your argument is based your personal expectations, and any "additional
evidence" which you _allege_ Weinreb has supplied can at best be his
personal opinion.
The Specification itself has seen common lisp implementations which have
apparently confounded your expectation. I can say they have not
confounded mine, 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]
--
Madhu
Kenneth Tilton
> [First Order] Logic and valid inference are tools which are not powerful
> enough to expose such charlatanism. It is necessary to step outside the
> formal framework to see what you are doing here.
We'll know you see what he is doing when you step outside the thread.
kt
Ron Garret
Tamas K Papp <tkp...@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
Ron Garret
Madhu <eno...@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
Pascal J. Bourguignon
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__
Madhu
* Ron Garret <rNOSPAMon-F3808...@news.albasani.net> :
Wrote on Wed, 14 Oct 2009 02:18:16 -0700:
| In article <m3eip6v...@moon.robolove.meer.net>,
| Madhu <eno...@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
Björn Lindberg
> On 2009-10-12, Madhu <eno...@meer.net> wrote:
>>
>> * Vassil Nikolov <snzy6nh...@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...@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
Ron Garret
wrote:
> 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.
This is indeed an valid argument, but it is not a slam-dunk (and hence
it is not a refutation of the claim of ambiguity). The reason it is not
a slam-dunk is because this sentence occurs in the context of an example
meant to elucidate *when* initforms are evaluated. One could therefore
reasonably argue that the sentence is not meant to apply in general. In
particular, the sentence's reference to "the constructor function" does
*not* necessarily imply that there is a single constructor function in
play in all cases. The possibility remains that in the case of an
:included structure there are two constructor functions, one for the
including structure and one for the included structure, and hence two
lexical environments. Of course, the spec does not *require* this
behavior (if it did, there would be no ambiguity and we would not be
having this discussion). But it doesn't rule it out either.
rg
Ron Garret
Madhu <eno...@meer.net> wrote:
> | 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.
I'm pretty sure he meant what he wrote. But I'm sure he's easy to
contact. Why don't you ask him?
> [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.
What does that have to do with anything?
> 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.
You expect more than that. You expect DEFSTRUCT to behave like DEFMACRO
rather than DEFUN with respect to the surrounding lexical environment.
You expect that that expanded definition will NOT make any reference to
an initialization function for an included structure that was defined in
some other lexical environment. But THOSE expectations have no basis in
the spec. That is simply your own personal prejudice.
A perfectly reasonable expansion of (defstruct foo x (:include baz))
would be something like:
(progn
(internal-define-struct foo :slots '(x) :include '(baz))
(defun internal-initialize-foo (f args)
(initialize-slot f 'x (extract-arg args 'x))
(defun make-foo (&rest args)
(let ((struct (internal-make-struct (internal-struct-size 'foo))))
(internal-initialize-foo struct args)
(internal-initialize-baz struct args :offset (length '(x)))
...)
where internal-initialize-baz, of course, gets defined in the expansion
of (defstruct baz ...) and therefore captures the lexical environment
surrounding THAT defstruct.
> As a CL programmer I am not accustomed to seeing opaque undebuggable
> closures when I do this.
Please note that the above expansion contains no opaque, undebuggable
closures.
> 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
The specification may indicate this. It may even strongly imply this.
But it does not *require* this.
> So I know EXACTLY (by the principles of referential
> transparency) what is evaluated in the one lexical environment (of the
> macro) of the defstruct.
Please note that in the above example you do know exactly what is
evaluated in the lexical environment 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.
Yes, it does. As I have shown above.
> 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.
Maybe some day the world will be enlightened enough to reject lexical
scoping entirely and return to the halcyon days where everything was
dynamically scoped and we didn't have to argue about things like whether
or not DEFVAR does the Right Thing either. Until that happens, I'm
afraid you're stuck with the spec as it is written. And as it is
written it is ambiguous. I'm sorry you don't like it, but that's the
way it is.
rg
Björn Lindberg
> In article <9mpy6ne...@runa.se>, bj...@runa.se (Bj�rn Lindberg)
> wrote:
>
>> 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.
>
> [...] In particular, the sentence's reference to "the constructor
> function" does *not* necessarily imply that there is a single
> constructor function in play in all cases.
But there is. Make-foo is the constructor function of the structure
foo.
> The possibility remains that in the case of an
> :included structure there are two constructor functions, one for the
> including structure and one for the included structure, and hence two
> lexical environments.
Such an implementation is not compatible with the requirement that the
slot initforms evaluate as if they were initforms to keyword arguments.
If I were to speculate, I would guess that in some ancient Lisp,
:include had a very literal meaning to insert s-expressions of one
structure definition into another. If this were the background, it would
explain why the spec does not clearly state the environment of
evaluation, despite doing so for defclass. Many apparent ambiguities in
the spec can be explained knowing the behaviour of Lisps leading up to
CL. It would be interesting to have Kent Pitman's input on the subject.
Bj�rn Lindberg
Ron Garret
wrote:
> Ron Garret <rNOS...@flownet.com> writes:
>
> > In article <9mpy6ne...@runa.se>, bj...@runa.se (Björn Lindberg)
> > wrote:
> >
> >> 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.
> >
> > [...] In particular, the sentence's reference to "the constructor
> > function" does *not* necessarily imply that there is a single
> > constructor function in play in all cases.
>
> But there is. Make-foo is the constructor function of the structure
> foo.
Let me be more precise: the sentence's reference to "the constructor
function" does not preclude the possibility that there are additional
constructor/initialization functions created behind the scenes that are
invoked by make-foo (assuming now that FOO :includes BAZ) and which
capture the lexical environment where BAZ is defined.
> > The possibility remains that in the case of an
> > :included structure there are two constructor functions, one for the
> > including structure and one for the included structure, and hence two
> > lexical environments.
>
> Such an implementation is not compatible with the requirement that the
> slot initforms evaluate as if they were initforms to keyword arguments.
As I just explained, this is not a requirement, it is part of an
expository sentence pertaining to an example that has nothing to do with
:included structs.
> the spec does not clearly state the environment of evaluation
That is exactly the point I am trying to make. (And it is the *only*
point I am trying to make.)
rg
netsettler
> Ron Garret <rNOSPA...@flownet.com> writes:
> ...
> > The possibility remains that in the case of an
> > :included structure there are two constructor functions, one for the
> > including structure and one for the included structure, and hence two
> > lexical environments.
>
> Such an implementation is not compatible with the requirement that the
> slot initforms evaluate as if they were initforms to keyword arguments.
Why not? Can't they be used in each of several situations?
> If I were to speculate, I would guess that in some ancient Lisp,
> :include had a very literal meaning to insert s-expressions of one
> structure definition into another. If this were the background, it would
> explain why the spec does not clearly state the environment of
> evaluation, despite doing so for defclass. Many apparent ambiguities in
> the spec can be explained knowing the behaviour of Lisps leading up to
> CL. It would be interesting to haveKentPitman'sinput on the subject.
The thing to understand is that ANSI CL, as a process, was not by
nature a language design process. We didn't sit around for every
language feature and say "How should this be? Is this the right way to
describe what we want?"
We began with a "base document" (CLTL) and we assumed that the
community was using this already as a de facto standard.
Consequently, for things we had time to reconsider, we did so. But
for the other things, we just took the text from CLTL literally. Of
course, we rearranged a lot of that text, so it's less apparent. But
the TeX source files (you can get them from parcftp) contain
annotations in a lot of places saying where various sentences came
from so that if challenged we can point to CLTL and say "It already
decided this." Features like DEFSTRUCT were mostly left intact from
CLTL because they were mostly* only ever there for compatibility
anyway and redefining something you were trying to be compatible with
seemed like a bad idea. I did in a number of places try to clean up
the wording, but mostly only where I was pretty sure my replacement
wording would mean the same thing. Sometimes, when the wording was
highly specific like this, I probably just left it intact from
Steele's account in CLTL, so I'd look up DEFSTRUCT if I had more time
and probably you'd find it there.
* I said "mostly only ever there" because theoretically we also would
have liked to redefine DEFSTRUCT to have a well-understood (rather
than obscure) structure class that the MOP would work on (better and
more portably), etc. But we never got time to do that. If we had
done that, then obviously the purpose would have gone beyond mere
compatibility. DEFSTRUCT is not an obviously dead idea, it's just
that to the degree we didn't have the resources to develop it, it is
what it is.
Anyway, the main reason I write this (besides being invited to
comment) is to defend against any implication/inference that might
suggest that the design processs was that we (and particularly I) sat
down at one point and said "Let's have DEFSTRUCT. What will it do?"
That was done, but it was done for CLTL1 (1984) not for ANSI (1994).
By the time of ANSI, it was settled. And, to the extent it was done
for CLTL1, it was somewhat dictated by MACLISP (maclisp.info) where
there already was a DEFSTRUCT. Steele cleaned it up a bit--in CLTL he
had the charter to do that without having to get a vote; in ANSI CL, I
tried never to make a non-editorial change (that is, one that would be
programmatically visible) in the text without an X3J13 vote to back me
up. The editing process was as much an exercise in trust as in
design; had I been doing "helpful technical changes" while I was
editing, the first time it was discovered, I've have been sacked and
the entire process would have been thrown into chaos.
You'll note even here I haven't commented on the technical merit of
the topic under discussion. I don't have time to research it today in
order to have an opinion. I thought I'd just share a few procedural
observations.
Tim Bradshaw
> 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.
And indeed such closures are being created in the simple case (ie no
inclusion).
> 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.
I don't agree with Ron about much, but yes. It's not bad design in
fact: it's catastrophically awful design. Accidental name capture like
this is the kind of thing that makes the hygienic macro people whine
about CL.
I haven't read much of the rest of this thread yet, but come on people,
be serious: *If* the standard says this (and as a native speaker of
English I think it is ambiguous), it is a bug in the standard. Let's
not get held to bugs which clearly have such horrible effects.
Tim Bradshaw
> 5. The fact that at least one member of the ANSI committee (Dan
> Weinreb) has gone on the record to say that the spec is ambiguous.
For what it's worth, here is another one saying the same thing. (I
don't claim Dan's authority, and I was not on the committee until after
the standard was finished.)
Tim Bradshaw
> I believe he means "He" did not think about this.
I believe he means that nobody thought of it.
Alan Bawden
>
> 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.
In the version of DEFSTRUCT that I wrote in 1978 (that everybody used
before we had Common Lisp), the initforms were just substituted directly
into the code generated by the constructor macro. That wasn't very pretty,
but most of the time it didn't matter because initforms contained nothing
but constants and global variables. It would have been hard to do better,
because I had to support MacLisp (which had no closures!).
The language in the Common Lisp specification that you are all discussing
is there because the committee recognized that the initform behavior of my
original DEFSTRUCT was undesirable, and that those forms really should be
treated as expressions that were tied to the lexical environment in which
they originally occurred.
It is true that the interaction with :INCLUDE wasn't explicitly spelled out
(almost certainly because the issue didn't occur to the committee at the
time) but it is clear that their -intent- was to elevate those forms from
contextless fragments of code into true expressions that could refer to the
lexical environment in which they occurred. It would be a weirdly perverse
reading of the specification (and history) to claim that the committee only
wanted to go half-way towards making initforms true expressions by giving
them a new lexical environment each time their containing DEFSTRUCT is
:INCLUDEd.
Tim Bradshaw
> There is no :include construct for DEFCLASS (and hence no corresponding
> ambiguous specification) so I don't see how this is relevant.
That's so, but the nearest equivalent works (in the way we both believe
to be) right:
(let ((x 3))
(defclass foo ()
((s :accessor foo-s :initform x))))
(let ((x 4))
(defclass bar (foo)
()))
Madhu
Wrote on 14 Oct 2009 14:13:33 -0400:
| In the version of DEFSTRUCT that I wrote in 1978 (that everybody used
| before we had Common Lisp), the initforms were just substituted directly
| into the code generated by the constructor macro. That wasn't very pretty,
| but most of the time it didn't matter because initforms contained nothing
| but constants and global variables. It would have been hard to do better,
| because I had to support MacLisp (which had no closures!).
|
| The language in the Common Lisp specification that you are all
| discussing is there because the committee recognized that the initform
| behavior of my original DEFSTRUCT was undesirable, and that those
| forms really should be treated as expressions that were tied to the
| lexical environment in which they originally occurred.
So this issue about which lexical environment the inintform is evaluated
_did_ come up.
| It is true that the interaction with :INCLUDE wasn't explicitly
| spelled out (almost certainly because the issue didn't occur to the
| committee at the time)
Given they had your implementation, the claim (if a committe member so
makes it now) that this thought did not occur to ANYBODY in the
committee AT ALL is both preposterous and impossible to believe, now
since you also state that the motivating reason for including the
wording [regarding lexical environments] in the first place was from
hygiene considerations.
| but it is clear that their -intent- was to elevate those forms from
| contextless fragments of code into true expressions that could refer
| to the lexical environment in which they occurred.
The spec as it stands today defines how the initforms are substitued
[verbatim, the alternative makes no sense] into the optional arguments
of MAKE-STRUCTURE constructor forms of the _included_ structure which
are built up in the defstruct macro.
| It would be a weirdly perverse reading of the specification (and
| history) to claim that the committee only wanted to go half-way
| towards making initforms true expressions by giving them a new lexical
| environment each time their containing DEFSTRUCT is :INCLUDEd.
Regardless of intent, the definition in the spec today [based on your
implementation] is both reasonable and it provides a predictable model
for behaviour of code, especially in the face of side effects which are
not prohibited by the language, and given the facts that the language
does not make hygiene its prime directive. And has a defmacro system
(which is also used for including code fragments) that behaves in a
similar way.
--
Madhu
Pascal Costanza
I find this very easy to believe. Such problems and the fact that they
are discovered only very late occur all the time when defining languages
or libraries.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Madhu
Wrote on Wed, 14 Oct 2009 23:59:55 +0200:
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.
--
Madhu
Pascal Costanza
This assumes they had infinite time to think about each and every
potential decision they had to made. That's a very strong, and very
unlikely assumption.
Heck, they got prog2 wrong. ;) This issue being discussed here is much
less likely to stumble over...
Madhu
* Pascal Costanza <7jn1k2F...@mid.individual.net> :
Wrote on Thu, 15 Oct 2009 00:28:19 +0200:
| This assumes they had infinite time to think about each and every
| potential decision they had to made. That's a very strong, and very
| unlikely assumption.
No, this does not assume infinite time, I am not sure what you are
arguing or if you are just avoiding my point. The internal evidence is
all I am basing my statement on.
The claim that the thought X did not occur at all can only be a
convenient after the fact fiction after the thought X did in fact occur,
given that X was the precisely thought on the mind at the time of
proceedings.
--
Madhu
Pascal Costanza
Whatever...
Vassil Nikolov
On 14 Oct 2009 14:13:33 -0400, Alan Bawden <al...@shaggy.csail.mit.edu>
wrote about the origin and standardization of DEFSTRUCT.
Thank you very much.
* * *
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 (as I
think has already been said in this thread), and moreover it is easy
for the user to achieve such behavior in any implementation by
simply rewriting
(let ((x 0))
(defstruct foo (a x)))
along the lines of
(let ((x 0))
(progn (defun #1=#:initval () x)
(defstruct foo (a (#1#)))))
so then e.g. the following tests pass:
(progn (defstruct (bar (:include foo)))
(let ((x 1)) (declare (ignorable x)) (defstruct (baz (:include foo))))
(assert (zerop (bar-a (make-bar))))
(assert (zerop (let ((x 1)) (declare (ignorable x)) (bar-a (make-bar)))))
(assert (zerop (baz-a (make-baz))))
(assert (zerop (let ((x 1)) (declare (ignorable x)) (baz-a (make-baz))))))
(it doesn't look too difficult to produce a macro that does the
above rewriting in the general case).
---Vassil.
--
"Even when the muse is posting on Usenet, Alexander Sergeevich?"
Madhu
* Vassil Nikolov <snztyy1...@luna.vassil.nikolov.name> :
Wrote on Thu, 15 Oct 2009 00:00:15 -0400:
| 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 (as I
| think has already been said in this thread),
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.
| and moreover it is easy for the user to achieve such behavior in any
| implementation by simply rewriting
[snip]
This will work for at most 1 level of inclusion.
In the face of the file compiler operation, unless you change the
wording in parts of the standard, you cannot expect to do this portably
unless the included defstruct is at a toplevel form --- without a
lexical environment.
i.e. (in your example) you cannot expect
(let ((SOMEENV)) (defstruct CALF (:include baz)))
to be portably compiled.
--
Madhu
Vassil Nikolov
On Thu, 15 Oct 2009 09:57:24 +0530, Madhu <eno...@meer.net> said:
> ...
> This will work for at most 1 level of inclusion.
I am too curious about this particular remark. Are you saying that
the example below will not work, or are you saying something else?
(let ((x 0))
(progn (defun #1=#:initval () x)
(defstruct foo (a (#1#)))))
(progn (let ((x 1)) (declare (ignorable x)) (defstruct (baz (:include foo))))
(let ((x 1)) (declare (ignorable x)) (defstruct (quux (:include baz))))
(assert (zerop (baz-a (make-baz))))
(assert (zerop (let ((x 1)) (declare (ignorable x)) (baz-a (make-baz)))))
(assert (zerop (quux-a (make-quux))))
(assert (zerop (let ((x 1)) (declare (ignorable x)) (quux-a (make-quux))))))
Madhu
* Vassil Nikolov <snzeip5...@luna.vassil.nikolov.name> :
Wrote on Thu, 15 Oct 2009 00:52:12 -0400:
| On Thu, 15 Oct 2009 09:57:24 +0530, Madhu <eno...@meer.net> said:
|> ...
|> This will work for at most 1 level of inclusion.
|
| I am too curious about this particular remark. Are you saying that
| the example below will not work, or are you saying something else?
Sorry, looking at what I said, I believe I made a mistake in saying it
is required to work at all if put in a file and compiled.
I believe the Specification promises that the file compiler will
recognize an earlier defstruct for Inclusion via INCLUDE only if the
earlier defstruct appeared as a toplevel form.
In your example the included defstruct is not defined as a top level
form
--
Madhu
Tamas K Papp
> Heck, they got prog2 wrong. ;) This issue being discussed here is much
How is prog2 wrong? (Or if this is a joke, sorry, I am not getting it).
Tamas
Pascal Costanza
Read the HyperSpec entry. Madhu probably thinks they have very deeply
thought about the wording there as well, and will argue that all CL
vendors implement this incorrectly... ;)
Scott Burson
> 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.
-- Scott
Tim Bradshaw
> 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.
Tim Bradshaw
> How is prog2 wrong?
"prog2 evaluates first-form, then second-form, and then forms, yielding
as its only value the primary value yielded by first-form."
Tamas K Papp
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).
Tamas
Tim Bradshaw
> 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.)
Tim Bradshaw
> 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.
Thomas A. Russ
> 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
Don Geddis
> On Thu, 15 Oct 2009 19:20:30 +0100, Tim Bradshaw wrote:
>> On 2009-10-15 08:41:53 +0100, Tamas K Papp <tkp...@gmail.com> said:
>>> How is prog2 wrong?
> 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/ d...@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
Madhu
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
Madhu
* Tim Bradshaw <2009101519361950073-tfb@cleycom> :
Wrote on Thu, 15 Oct 2009 19:36:19 +0100:
| On 2009-10-15 05:57:24 +0100, Madhu <eno...@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
Madhu
[I can respond to you now you aren't using google groups]
* Tim Bradshaw <2009101519190016807-tfb@cleycom> :
Wrote on Thu, 15 Oct 2009 19:19:00 +0100:
Well, the internal evidence here suggests they may be lying through
their teeth
--
Madhu
netsettler
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
Madhu
do not wish to follow up as I believe all the points have been made]
* Don Geddis <87pr8of...@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
Alan Bawden
> ...
> 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.
Ron Garret
Madhu <eno...@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 <87pr8of...@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
Tamas K Papp
> Tamas K Papp <tkp...@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 <tkp...@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
Madhu
Wrote on 16 Oct 2009 01:21:35 -0400:
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
Madhu
* Tamas K Papp <7jqli2F...@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
Tamas K Papp
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
Madhu
* Tamas K Papp <7jqmdsF...@mid.individual.net> :
Wrote on 16 Oct 2009 07:41:48 GMT:
|> 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?
The alleged ambiguity here is can be seen as a result of an
interpretation that is based on a concept of `hygiene' as defined by
scheme doctors. If the resolution of the ambiguity is based on the
principle of `hygiene[1]', and notions of "good design" and "the lambda
way", one will encounter the fact that other parts of the CL language do
not in fact accord with this principle of hygiene (which is used to
decide the ambiguity in favour of one interpretation), and those other
features can be seen as bugs (with respect to this principle), which
would also need fixing.
--
Madhu
Tamas K Papp
While your obsession with Scheme is quite entertaining, I don't really
see how macros are "ambiguous", and I could not find any arguments to
this effect in the above paragraph.
Nevertheless, I see that you managed to drag some of the Scheme bogeys
that populate your nightmares into it. I think that your
Scheme-o-phobia is clouding your thinking. If you are going crazy, I
would recommend another delusion, especially if you want to reach the
stage when you grow a beard and sleep in subway stations. If you go
around murmuring "Damn HYGIENE! The wanted me to go the LAMBDA WAY!",
people are gonna be puzzled. Pick something else, eg UFOs or Fidel
Castro controlling your brain with radio waves.
Cheers,
Tamas
Ron Garret
Madhu <eno...@meer.net> wrote:
You are seriously misinterpreting the reasoning behind the prevailing
view, and the implications of the fact that CL doesn't have hygienic
macros. Name capture (I presume you know what that means) is
universally considered a problem, not a feature. Hygiene is one
solution to this problem, but it has drawbacks. Because of those
drawbacks, CL uses a different solution (lexical scoping, packages, and
separation of function and value namespaces) to solve the problem.
Opinions differ over the relative merits of these solutions, but
opinions do not differ about the underlying problem.
The reason your interpretation of the spec is being universally rejected
is that it DELIBERATELY REINTRODUCES THE UNDERLYING PROBLEM of name
capture when it is not necessary to do so. The prevailing
interpretation is not a rejection of CL principles and a flight to
hygiene, it is the proper recognition of what lexical scoping is, what
it is for, and when to apply it. If you don't get that then you don't
understand lexical scoping and why it replaced dynamic scoping as the
primary binding discipline in CL.
BTW...
> have a READer which works on text strings
Is this really what you meant to say? I believe the READer already does
this.
rg
Madhu
* Tamas K Papp <7jqno3F...@mid.individual.net> :
Wrote on 16 Oct 2009 08:04:19 GMT:
|> * Tamas K Papp <7jqmdsF...@mid.individual.net> : Wrote on 16 Oct
|> 2009 07:41:48 GMT:
|>
|> |> 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,
|> | Besides, I was talking about fixing ambiguities in the standard.
|> | How do, for example, dual namespaces and macros count as ambiguous?
|>
|> The alleged ambiguity here is can be seen as a result of an
|> interpretation that is based on a concept of `hygiene' as defined by
|> scheme doctors. If the resolution of the ambiguity is based on the
|> principle of `hygiene[1]', and notions of "good design" and "the
|> lambda way", one will encounter the fact that other parts of the CL
|> language do not in fact accord with this principle of hygiene (which
|> is used to decide the ambiguity in favour of one interpretation), and
|> those other features can be seen as bugs (with respect to this
|> principle), which would also need fixing.
|
| While your obsession with Scheme is quite entertaining, I don't really
| see how macros are "ambiguous", and I could not find any arguments to
| this effect in the above paragraph.
If you see the ^^^ above, notice you asked for the `intent of the
lawmaker'. If the intent is determined to be hygiene, then it will
follow that an unhygenic defmacro system is unambiguously against the
intent of the law.
I appreciate your concern for my delusions, but the fact of this case is
there is a perfectly valid consistent interpretation (with an
implementational and an evaluation model in CL) which makes an
alternative interpretation unnecessary. Go back to the above paragraph
to see the single basis for the alternative interpretation; after seeing
my reply to Don Geddis. Or would you that I repeat myself just to poke
fun at delusions.
The allegation that this "broken interpretation" is "obviously wrong" to
"all CL users except me" prompted the intial comment to you that the
next version of CL being mooted by this issue might as well start with
hygiene (the intent of the law) on page 1 and eliminate all the
"ugliness" in CL which goes against it. The out of work scheme
committee can regroup and start with the CL users and help them clean up
the next version of their spec. oops q:
--
Madhu
Kaz Kylheku
To implement Lisp (or any other language), you have to a cunning S.O.B.
who knows much more than just the body of the defining document.
Tim Bradshaw
> 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.
I don't think that's the case. Obviously these features help, but I
think you can get by with assiduous use of MAKE-SYMBOL or GENSYM. I
may be wrong.
Tim Bradshaw
> The alleged ambiguity here is can be seen as a result of an
> interpretation that is based on a concept of `hygiene' as defined by
> scheme doctors.
However, it is not actually based on that. I have no time for Scheme
at all, I like CL's macro system, yet I see the spec as ambiguous.
Tim Bradshaw
> Well, the internal evidence here suggests they may be lying through
> their teeth
I think you should probably stop now: you've dug yourself a pretty deep
pit. I'm certainly nto going to respond further to you (I wasn't
intending myself as one of the people who was there BTW: I wasn't).
Ron Garret
Tim Bradshaw <t...@cley.com> wrote:
There are two kinds of symbol capture. GENSYM only solves one of them.
Madhu's DEFSTRUCT (re-)introduces the other kind.
rg
Vassil Nikolov
Silly though it is, I wish the intent of this pun was more ambiguous...
---Vassil.
--
"Even when the muse is posting on Usenet, Alexander Sergeevich?"
Tim Bradshaw
> There are two kinds of symbol capture. GENSYM only solves one of them.
> Madhu's DEFSTRUCT (re-)introduces the other kind.
I'm confused, can you explain? Or may be I'm not. The traditional
bad-macro one is, I think, where you write something like:
(defmacro collecting (&body forms)
`(let ((.secret. '()))
(flet ((collect (x)
...))
,@forms)
.secret.))
Here COLLECT is meant to be introduced, but .SECRET. is not. So
instead you write
(defmacro collecting (&body forms)
(let ((sn (make-symbol "SECRET")))
`(let ((,sn '()))
(flet ((collect (x)
...))
,@forms)
,sn)))
Where the secret variable is now really secret.
I guess the bad-DEFSTRUCT one is kind of this inside out, where I've
done something like
(let ((x ...))
(lambda (y)
... x
))
But somehow what I've got has not closed over the X so it will "see"
other bindings of X where it is used.
Is that what you mean?
Ron Garret
Tim Bradshaw <t...@cley.com> wrote:
> On 2009-10-17 00:31:09 +0100, Ron Garret <rNOS...@flownet.com> said:
>
> > There are two kinds of symbol capture. GENSYM only solves one of them.
> > Madhu's DEFSTRUCT (re-)introduces the other kind.
>
> I'm confused, can you explain? Or may be I'm not. The traditional
> bad-macro one is, I think, where you write something like:
>
> (defmacro collecting (&body forms)
> `(let ((.secret. '()))
> (flet ((collect (x)
> ...))
> ,@forms)
> .secret.))
>
> Here COLLECT is meant to be introduced, but .SECRET. is not. So
> instead you write
>
> (defmacro collecting (&body forms)
> (let ((sn (make-symbol "SECRET")))
> `(let ((,sn '()))
> (flet ((collect (x)
> ...))
> ,@forms)
> ,sn)))
>
> Where the secret variable is now really secret.
That's right.
There are two types of capture situations, those that involve code that
is passed into the macro as an argument and appears in the macro
expansion, and code that surrounds the macro. AFAIK, the two types of
capture don't really have names, so I'll coin some new terminology:
let's call them INWARD and OUTWARD capture respectively. What you have
just described in inward capture, and it is fixed using gensyms.
> I guess the bad-DEFSTRUCT one is kind of this inside out, where I've
> done something like
>
> (let ((x ...))
> (lambda (y)
> ... x
> ))
>
> But somehow what I've got has not closed over the X so it will "see"
> other bindings of X where it is used.
>
> Is that what you mean?
I'm not sure, because this is not an example of capture.
The problem with Madhu's semantics is outward capture, but kind of in
reverse from the usual situation. The usual situation is something like
this:
(defun my-helper (...) (something))
(defmacro mac (...) `(... (my-helper ...) ...))
and now a user does:
(flet ((my-helper (...) (something-different)))
(mac ...))
This is the kind of capture that is solved by separating value and
function namespaces and adding packages. In a Lisp-1 without packages
there is the following classic screw case:
(define-macro lisp1-macro (...) (... (list ...) ...))
(defun foo (list) (... (lisp1-macro ...) ...))
Hopefully it's obvious how Lisp-2 and packages fix this.
The point is, the macro's proper operation depends on the environment in
which it is *used*. LISP1-MACRO depends on LIST being bound -- AT THE
POINT OF INVOCATION -- to a function that makes lists. MAC depends on
MY-HELPER being FBOUND to a function that does "something" (as opposed
to "something-else"). If the environment is not correct, the macro will
fail.
Madhu's DEFSTRUCT has this exact same problem. Consider the canonical
example:
(let ((x ...)) (defstruct foo (slot (... x ...))))
Under Madhu's semantics, FOO acts like a macro that now depends on X
being bound at the point of :inclusion (which is the DEFSTRUCT analog of
macro invocation under Madhu's semantics). i.e. the following will fail:
(defstruct (baz (:include foo)) ...)
because X is not bound here, i.e. the environment is not correct.
rg
Tim Bradshaw
> I'm not sure, because this is not an example of capture.
Yes, it's not. I think I was thinking of some alternative dialect of
Lisp where it would be though clearly not being coherent (I *think*
that I remember things in Cambridge Lisp, which was the first Lisp I
used, where things like this gave problems.
I like your terminology though: i was thinking of upward & downward
(based on the funarg terminology) but that's not right because that was
based on stacks, and this is based on position in source.
So, I think:
Inward capture is where something wraps itself around your code and
inserts names it should not into the scope of your code. This can be
resolved by just introducing such names.
Outward capture is where something inserts code within the scope of
your code, and that code depends on names which your code may (or may
not) have introduced. In general this is harder, because of things
like your FLET case, but in many specific cases it's not that hard (for
instance the DEFSTRUCT case).
Ron Garret
Tim Bradshaw <t...@cley.com> wrote:
> On 2009-10-17 16:59:16 +0100, Ron Garret <rNOS...@flownet.com> said:
>
> > I'm not sure, because this is not an example of capture.
>
> Yes, it's not. I think I was thinking of some alternative dialect of
> Lisp where it would be though clearly not being coherent (I *think*
> that I remember things in Cambridge Lisp, which was the first Lisp I
> used, where things like this gave problems.
>
> I like your terminology though: i was thinking of upward & downward
> (based on the funarg terminology) but that's not right because that was
> based on stacks, and this is based on position in source.
>
> So, I think:
>
> Inward capture is where something wraps itself around your code and
> inserts names it should not into the scope of your code. This can be
> resolved by just introducing such names.
I presume you meant "... by just NOT introducing such names" i.e. by
using gensyms. That's right.
> Outward capture is where something inserts code within the scope of
> your code, and that code depends on names which your code may (or may
> not) have introduced. In general this is harder, because of things
> like your FLET case,
I'd phrase it slightly differently: outward capture is where the macro
expansion contains a free reference, i.e. a reference that is not bound
by the macro expansion itself. You have a choice of environment in
which to resolve that free reference. You can resolve it in the
environment where the macro is defined (this is what hygienic macros do)
or you can resolve it in the environment where the macro is invoked
(this is what CL does).
Note that the reason hygienic macros are hairy and tend to be associated
with weird-looking things like SYNTAX-RULES is that in a fully general
macro facility it is hard to figure out what the free references *are*.
In a fully general DEFMACRO it is actually impossible to do this at
macro-definition time because that would require solving the halting
problem. SYNTAX-RULES constrains the kinds of computations that
macro-expanders can perform in order to make the problem of identifying
the potential free references tractable at macro-definition time.
Note that imposing this kind of constraint is not actually necessary
because you can elect to identify the free references at macro-expansion
time, which is obviously a tractable problem (assuming the macro
expansion terminates of course). There's an interesting recent result
due to Pascal Costanza and his students that shows that not only is the
problem tractable, but that it can be done without a code walker.
> but in many specific cases it's not that hard (for
> instance the DEFSTRUCT case).
The DEFSTRUCT case is a complete red herring because the spec is
ambiguous, so you can choose whether to use (unhygienic-)macro-like
semantics with all its attendant problems, or function-like semantics.
This is notwithstanding the fact that DEFSTRUCT is a macro. DEFUN is a
macro too, but obviously the things that DEFUN defines have
function-like semantics. It's a no-brainer that function-like semantics
is the better choice because then everything is lexically scoped and the
capture issues simply evaporate.
rg
Madhu
Wrote on Sat, 17 Oct 2009 21:01:33 +0100:
| Inward/Outward capture
[I see no need to invent new terminology which is then used to wrongly
address the issues at hand]
You may be interested in the propopsal to bind initforms to new names
(via gensym) in the defstruct-generated-constructor's lambda-list which
was termed NOT-BOUND[1].
[NOTE however that this has issues with boa constructors and also will
not work when there is any ordering of evaluation in the initforms
(which can be theoretically imposed by the user)]
[1] http://www.lispworks.com/documentation/HyperSpec/Issues/iss111_w.htm
Issue DEFSTRUCT-CONSTRUCTOR-SLOT-VARIABLES (not part of the Common Lisp
Standard).
--
Madhu
Ron Garret
Madhu <eno...@meer.net> wrote:
> * Tim Bradshaw <2009101721013316807-tfb@cleycom> :
> Wrote on Sat, 17 Oct 2009 21:01:33 +0100:
>
> | Inward/Outward capture
>
> [I see no need to invent new terminology which is then used to wrongly
> address the issues at hand]
That's because you apparently don't understand the issues at hand.
> You may be interested in the propopsal to bind initforms to new names
> (via gensym) in the defstruct-generated-constructor's lambda-list which
> was termed NOT-BOUND[1].
This has nothing to do with the topic at hand, which is whether the
initforms for slots in :included structs are lexically scoped. This has
to do with what happens when the symbol naming a slot has been
proclaimed special. These have nothing whatsoever to do with one
another.
rg
Madhu
* Ron Garret Wrote on Sat, 17 Oct 2009 22:28:24 -0700:
[I said I would not respond to you again but you have compelled me to
respond. there are clear issues of right and wrong, appropriate and
inappropriate, acceptable and unacceptable. These all have to be
identified and delineated. What you are doing on this newsgroup is
unacceptable]
| That's because you apparently don't understand the issues at hand.
I make the same claim of you.
| This has nothing to do with the topic at hand
I never claimed they did. You have again misrepresented what I have said
and are forcing me to correct an alleged mistake I did not make.
| which is whether the initforms for slots in :included structs are
| lexically scoped. This has to do with what happens when the symbol
| naming a slot has been proclaimed special. These have nothing
| whatsoever to do with one another.
Anyone capable of rational thought you can think through the issues will
see that they do have an inseperable bearing.
Stop wasting our time.
--
Madhu
Madhu
* Ron Garret Wrote on Sat, 17 Oct 2009 22:28:24 -0700:
[I said I would not respond to you again but you have compelled me to
respond. there are clear issues of right and wrong, appropriate and
inappropriate, acceptable and unacceptable. These all have to be
identified and delineated. What you are doing on this newsgroup is
unacceptable]
| That's because you apparently don't understand the issues at hand.
I make the same claim of you.
| This has nothing to do with the topic at hand
I never claimed they did. You have again misrepresented what I have said
and are forcing me to correct an alleged mistake I did not make.
| which is whether the initforms for slots in :included structs are
| lexically scoped. This has to do with what happens when the symbol
| naming a slot has been proclaimed special. These have nothing
| whatsoever to do with one another.
Anyone capable of rational thought who can think through the issues will
see that they do have an inseparable bearing.
Ron Garret
Madhu <eno...@meer.net> wrote:
> * Ron Garret Wrote on Sat, 17 Oct 2009 22:28:24 -0700:
>
> [I said I would not respond to you again but you have compelled me to
> respond. there are clear issues of right and wrong, appropriate and
> inappropriate, acceptable and unacceptable. These all have to be
> identified and delineated. What you are doing on this newsgroup is
> unacceptable]
>
> | That's because you apparently don't understand the issues at hand.
>
> I make the same claim of you.
Yes, but like every other claim that you have made in this thread, you
don't back it up with any evidence or argument. You merely assert it.
> | This has nothing to do with the topic at hand
>
> I never claimed they did.
That's true. But if we're going to play that game, then I never claimed
that you made such a claim.
You can't have it both ways. Either it is implicit when making a
comment in a thread that it has something to do with what has gone
before, or it is not. You can't choose to apply one standard to
yourself and another to others. (Unless you are a hypocrite. Are you a
hypocrite?)
> You have again misrepresented what I have said
> and are forcing me to correct an alleged mistake I did not make.
No one on usenet can force anyone to do anything.
> | which is whether the initforms for slots in :included structs are
> | lexically scoped. This has to do with what happens when the symbol
> | naming a slot has been proclaimed special. These have nothing
> | whatsoever to do with one another.
>
> Anyone capable of rational thought who can think through the issues will
> see that they do have an inseparable bearing.
See my comment above about making claims unsupported by evidence or
argument.
rg
Tamas K Papp
> * Ron Garret Wrote on Sat, 17 Oct 2009 22:28:24 -0700:
>
> | which is whether the initforms for slots in :included structs are |
> lexically scoped. This has to do with what happens when the symbol |
> naming a slot has been proclaimed special. These have nothing |
> whatsoever to do with one another.
>
> Stop wasting our time.
I have been following this thread, and I have learned a lot from the
comments of Ron (also Tim and others), but I have not learned anything
from yours. I would think that it is _you_ who has been wasting
people's time (which is of course OK, this being Usenet, and at least
this thread was on-topic).
Best,
Tamas
Madhu
| I have been following this thread, and I have learned a lot from the
| comments of Ron (also Tim and others), but I have not learned anything
| from yours. I would think that it is _you_ who has been wasting
| people's time
It was not my intent to teach you anything in this thread. Perhaps you
have learnt _something_ but I doubt you have learnt anything on the
technical issues and tradeoffs involved in the topic at hand.
Again I suggest you read the URL posted above see[1] below, which
although is not a part of the standard indicates that people 20 years
ago had grappled with the issues and tradeoffs I _was_ interested in
learning and talking about in this thread, which was about DEFSTRUCT
semantics.
[1] <http://www.lispworks.com/documentation/HyperSpec/Issues/iss111_w.htm>
Instead all I get is invitation to respond to Ron's misrepresentation of
facts here and dishonest didactics which are calculated to appeal (to
newbies like you)
--
Madhu