From: "Drew Adams" <drew.adams@oracle.com>
To: "'Johan Bockgård'" <bojohan@gnu.org>,
"'Stefan Monnier'" <monnier@iro.umontreal.ca>
Cc: 'Lars Magne Ingebrigtsen' <larsi@gnus.org>,
'Andreas Schwab' <schwab@linux-m68k.org>,
9469@debbugs.gnu.org, 'Le Wang' <l26wang@gmail.com>
Subject: bug#9469: buffer-local variables seem to remember previous values
Date: Tue, 13 Sep 2011 11:52:42 -0700 [thread overview]
Message-ID: <F77936B5F3F64444886C84E4743879B5@us.oracle.com> (raw)
In-Reply-To: <87ehzktj6b.fsf@gnu.org>
> I think the "as written" bit is mildly confusing, and nearly
> falls into this trap:
>
> In other languages, an expression is text; it has no
> other form. In Lisp, an expression is primarily a Lisp
> object
Indeed. And I repeat that the misunderstanding comes from not knowing or not
sufficiently appreciating where those objects come from: what creates them.
That is what it would help to repeat/emphasize in the doc (e.g., in the context
of things like `quote', at least via a cross-reference).
Users need of course to understand that `quote' just returns its argument, but
that is not really the problem here, since they can misunderstand "its argument"
per the confusion that Johan referred to (text vs Lisp object).
What users might not get is that the argument that `quote' receives is a Lisp
object that has already been created. That might not be obvious to someone new
to Lisp. Especially when written as ', it is easy to misunderstand `quote' as
applying to the textual sexp that follows it, and not to a Lisp object.
The Lisp reader is kind of in the background of user awareness, so the question
of where the Lisp object comes from can mistakenly be answered by thinking that
it is `quote' that creates it based on the text/sexp that follows the '. That,
I think, is the gotcha that tripped up Le (and he's not alone).
In the case of a literal list argument to `quote', e.g. (quote (a b c)), users
need to understand that the Lisp reader (or loader) creates the list (a b c).
Given that understanding, what can also be missing is that, depending on the
Lisp, the Lisp reader might not create a _new_ list each time it encounters the
sexp "(a b c)". And in Emacs Lisp it in fact does not create a new list; it
reuses a previously created list, if available. (Is that always true for Elisp?
What about gc?).
This too is not obvious. And we can point out that literal strings are treated
differently - the reader does create a new, `eq'-unique string each time it sees
"abc". The bottom line is that we should communicate the lesson that you should
not depend on the Lisp reader creating a new object each time it reads a sexp.
It would be helpful to mention this and explain that the reader's treatment of
list sexps is similar to its treatment of symbol sexps (names). The treatment
of symbols is perhaps a bit easier to understand because we introduce the notion
of obarray, and because a symbol itself has an explicit string representation
(its name).
At a minimum, then, the manual's treatment of `quote' (and perhaps other things)
should reference some doc that explains the Lisp reader behavior well.
next prev parent reply other threads:[~2011-09-13 18:52 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-10 17:07 bug#9469: buffer-local variables seem to remember previous values Le Wang
2011-09-10 17:44 ` Drew Adams
2011-09-11 16:57 ` Le Wang
2011-09-11 17:56 ` Drew Adams
2011-09-11 18:08 ` Andreas Schwab
2011-09-11 18:49 ` Le Wang
2011-09-11 18:54 ` Lars Magne Ingebrigtsen
2011-09-11 19:18 ` Le Wang
2011-09-11 19:54 ` Lars Magne Ingebrigtsen
2011-09-12 4:39 ` Le Wang
2011-09-12 7:57 ` Andreas Schwab
2011-09-12 8:23 ` Le Wang
2011-09-12 8:35 ` Andreas Schwab
2011-09-12 14:30 ` Drew Adams
2011-09-12 15:06 ` Le Wang
2011-09-13 12:54 ` Stefan Monnier
2011-09-13 13:12 ` Le Wang
2011-09-13 15:00 ` Helmut Eller
2011-09-13 18:02 ` Johan Bockgård
2011-09-13 18:52 ` Drew Adams [this message]
2011-09-13 20:42 ` Helmut Eller
2011-09-15 18:14 ` Le Wang
2011-09-11 19:37 ` Helmut Eller
2011-09-11 19:46 ` Andreas Schwab
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=F77936B5F3F64444886C84E4743879B5@us.oracle.com \
--to=drew.adams@oracle.com \
--cc=9469@debbugs.gnu.org \
--cc=bojohan@gnu.org \
--cc=l26wang@gmail.com \
--cc=larsi@gnus.org \
--cc=monnier@iro.umontreal.ca \
--cc=schwab@linux-m68k.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.