···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) wrote in message news:<···············@famine.OCF.Berkeley.EDU>...
> No, quote *does* quote objects. You're confusing the issue with
> constant folding. The result of any two calls to the function FOO:
>
> (defun foo () '(1 2 3))
>
> will always be the same object (ie, EQ). This is true for both Common
> Lisp and ELisp. It's an issue of object identity, which is important
Sorry, but you are wrong. After experimenting a little bit I figured
out where the problem is:
The fact is, that even quoted lists are not constant objects. This is
because they are structures with pointers which can be manipulated.
Here your example:
(defun foo () '(1 2 3))
foo
(nconc (foo) '(bla))
(123 bla)
(foo)
(123 bla)
Now, everytime you call (ncon (foo) '(bla)) another bla will be
apended to the quoted list '(1 2 3). Try repeating this sometimes and
see how a call to (foo) will yield different results. I tried it in
emacs lisp.
Here is also the answer to my question. If '(1 2 3) was the result of
a macro call(defun foo () (macro-x)) there would be a difference
between interpreted and compiled code. When interpreted each call to
(foo) would produce a new list so the above effect would not happen.
But if the code is compiled, (macro-x) would be replaced with '(1 2 3)
and suddenly the program would behave differently.
Best regards,...
Hello!
thelifter <·········@gmx.net> wrote:
>[...]
>(defun foo () '(1 2 3))
>foo
>(nconc (foo) '(bla))
>(123 bla)
>(foo)
>(123 bla)
At least in Common Lisp (and we're in c.l.lisp, not in comp.emacs here!)
this is not allowed and the effects are undefined (or unspecified, I
don't find the exact position in the Hyperspec). Some implementations
may behave as in your example, though.
>[...]
Kind regards,
Hannah.
In article <············@c3po.schlund.de>,
Hannah Schroeter <······@schlund.de> wrote:
>Hello!
>
>thelifter <·········@gmx.net> wrote:
>>[...]
>
>>(defun foo () '(1 2 3))
>>foo
>
>>(nconc (foo) '(bla))
>>(123 bla)
>
>>(foo)
>>(123 bla)
>
>At least in Common Lisp (and we're in c.l.lisp, not in comp.emacs here!)
>this is not allowed and the effects are undefined (or unspecified, I
>don't find the exact position in the Hyperspec). Some implementations
>may behave as in your example, though.
It's not allowed *because* most implementations behave this way.
--
Barry Margolin, ······@genuity.net
Genuity, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
·········@gmx.net (thelifter) wrote in message news:<····························@posting.google.com>...
> ···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) wrote in message news:<···············@famine.OCF.Berkeley.EDU>...
> > No, quote *does* quote objects. You're confusing the issue with
> > constant folding. The result of any two calls to the function FOO:
> >
> > (defun foo () '(1 2 3))
> >
> > will always be the same object (ie, EQ). This is true for both Common
> > Lisp and ELisp. It's an issue of object identity, which is important
>
> Sorry, but you are wrong. After experimenting a little bit I figured
> out where the problem is:
>
> The fact is, that even quoted lists are not constant objects. This is
That's not what he said; he only said that the same object is returned
each time.
> because they are structures with pointers which can be manipulated.
This might be true of Emacs lisp, but it's not true of Common Lisp.
Note that you are off topic discussing Emacs Lisp in here; Emacs has
a perfectly adequate newsgroup. It seems that Emacs users are able to
find that newsgroup somehow, so you hardly ever see Emacs questions
posted in here.
You cannot experiment with Common Lisp because it's an abstract
language.
You can experiment with implementations of Common Lisp, but inferences
drawn from such experimentations don't generalize to the language.
Common Lisp has the notion of a constant object. The behavior is
undefined
if the program tries to modify such an object. Undefined behavior
means
that anything can happen. The modification may work, an error may be
signaled, the Lisp system can crash, etc.
Just because you find that it works on your implementation doesn't
mean
that it will port to the next one. And if it is not *documented* by
your implementation's reference manual, then it just may well be
working
by fluke, so that it can't even be trusted to be always reproducible.
The Emacs Lisp language is a dialect of Lisp that is very different
from
the ANSI standard Common Lisp. That dialect is defined by its single
implementation, so that in fact behavior which you observe
consistently,
and which is documented in the reference manual, is standard Elisp
behavior. That has nothing to do with Common Lisp.
> Here your example:
>
> (defun foo () '(1 2 3))
> foo
>
> (nconc (foo) '(bla))
> (123 bla)
See, look what the undefined behavior did! It glued the printed
representation of the three numbers 1 2 and 3 to produce 123.
Next time you won't be so lucky perhaps; demons might fly out of
your nose instead.
Also, I suggest you try calling (foo) again after doing the nconc.
Here is what happens in one Lisp implementation (remember, this does
not define the behavior for all of them, it is only one data point!)
(defun foo () '(1 2 3)) ==> FOO
(foo) ==> (1 2 3)
(nconc (foo) '(a b c)) ==> (1 2 3 A B C)
(foo) ==> (1 2 3 A B C)
From: Tim Bradshaw
Subject: Re: Help understanding ELISP Macro
Date:
Message-ID: <ey37kil42xc.fsf@cley.com>
* Kaz Kylheku wrote:
> The Emacs Lisp language is a dialect of Lisp that is very different
> from the ANSI standard Common Lisp. That dialect is defined by its
> single implementation, so that in fact behavior which you observe
> consistently, and which is documented in the reference manual, is
> standard Elisp behavior. That has nothing to do with Common Lisp.
I'm not sure it's even defined in elisp. I'm not sure if it's true
any more but in relatively recent history various emacs structures
would / could get copied into `pure space' when an image was dumped.
I think you might have had to do it by steam (with purecopy).
Attempts to modify these constants would result in an error. I
couldn't get this to happen with my emacs on things which I would have
thought might be pure, but I still have code in my .emacs which copies
things just so I could modify them.
And, of course the reason emacs did this was just exactly one of the
reasons that you don't want to go modifying constants: because they
are constant they can be on shared, read-only pages.
--tim
> ·········@gmx.net (thelifter) wrote in message news:<····························@posting.google.com>...
> > Sorry, but you are wrong. After experimenting a little bit I figured
> > out where the problem is:
> >
> > The fact is, that even quoted lists are not constant objects.
Note that I said the same object, (ie, EQ) was returned each time; not
a similar list. In fact, your example showed this. You modified the
cdr of the cons cell that was returned, and the next time you called
the function, the cdr was as you moldified it.
···@ashi.footprints.net (Kaz Kylheku) writes:
> This might be true of Emacs lisp, but it's not true of Common Lisp.
> Note that you are off topic discussing Emacs Lisp in here; Emacs has
> a perfectly adequate newsgroup.
For discussions of Emacs *Lisp*, I don't see the problem with asking
this newsgroup. For very emacs-y questions, I'd say the Emacs groups
are the only appropsriate ones, but for fiarly general lispy
questions, you might get better answers here, depending ... and the
subject line was very clearly labeled as Elisp.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
thelifter wrote:
>>will always be the same object (ie, EQ). This is true for both Common
>>Lisp and ELisp. It's an issue of object identity, which is important
>
> Sorry, but you are wrong.
Hmmm. This is interesting. At moments such as these I always like to
peruse the excellent article on equality by Kent Pitman[1]
:)w
[1] world.std.com/~pitman/PS/EQUAL.html
"...shoplifters, shoplifters, if your shop is too low we will lift
it..." -- Ivor Cutler
·········@gmx.net (thelifter) writes:
> ···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) wrote in message news:<···············@famine.OCF.Berkeley.EDU>...
>> No, quote *does* quote objects. You're confusing the issue with
>> constant folding. The result of any two calls to the function FOO:
>>
>> (defun foo () '(1 2 3))
>>
>> will always be the same object (ie, EQ). This is true for both Common
>> Lisp and ELisp. It's an issue of object identity, which is important
>
> Sorry, but you are wrong.
M-x ielm RET
ELISP> (defun my-test-1 () '(alpha beta gamma))
my-test-1
ELISP> (defun my-test-2 () (list 'alpha 'beta 'gamma))
my-test-2
ELISP> (eq (my-test-1) (my-test-1))
t
ELISP> (eq (my-test-2) (my-test-2))
nil
> After experimenting a little bit I figured out where the problem is:
>
> The fact is, that even quoted lists are not constant objects. This is
> because they are structures with pointers which can be manipulated.
> Here your example:
>
> (defun foo () '(1 2 3))
> foo
>
> (nconc (foo) '(bla))
> (123 bla)
>
> (foo)
> (123 bla)
>
> Now, everytime you call (ncon (foo) '(bla)) another bla will be
> apended to the quoted list '(1 2 3). Try repeating this sometimes and
> see how a call to (foo) will yield different results. I tried it in
> emacs lisp.
ELISP> (nconc (my-test-1) '(delta))
(alpha beta gamma delta)
ELISP> (my-test-1)
(alpha beta gamma delta)
ELISP> (nconc (my-test-2) '(delta))
(alpha beta gamma delta)
ELISP> (my-test-2)
(alpha beta gamma)
-- Oliver
[Thanks to Thomas F. Burdick and Barry Margolin who once explained
this for me.]
--
3 Fructidor an 210 de la R�volution
Libert�, Egalit�, Fraternit�!