From: Stefan Monnier <monnier@iro.umontreal.ca>
To: help-gnu-emacs@gnu.org
Subject: Re: Unreferenced symbols in closures, and a problem with closures in minor modes
Date: Tue, 28 May 2013 21:28:44 -0400 [thread overview]
Message-ID: <jwvppwabn47.fsf-monnier+gmane.emacs.help@gnu.org> (raw)
In-Reply-To: 1369780558.54419.YahooMailClassic@web141103.mail.bf1.yahoo.com
> (setq lexical-binding t)
> As expected, (let ((x 0)) (lambda () x)) -> (closure ((x . 0) t) nil x)
> But, (let ((x 0)) (lambda () 0)) -> (closure ((x . 0) t) nil 0)
> And, (lambda (x) x) -> (closure (t) (x) x)
> Why do closures' lexical environments include unreferenced symbols?
Because you're testing interpreted code: the interpreter does not take
the time to traverse the whole lambda body to figure out which variables
are free and which aren't. That could have a significant
performance impact. Rest assured that when you byte-compile this code,
only the free variables will be captured, tho.
> And why produce a closure with an empty environment, instead of just
> a lambda form?
Because the two are not equivalent in general: when running the body of
(closure (t) (x) <body>), `x' is lexically bound, whereas when running
the body of (lambda (x) <body>), `x' is dynamically bound.
> And I have a problem with unwanted closures in minor modes:
[...]
> Argh! Surely this is a misfeature?
Yup.
> I have no idea what the symbol i means or where it came from. If it
> were setting i to nil in the lexical environment, it would be (i),
> not i.
Indeed. A sole `var' in this environment is used to keep track of the
fact that a (defvar var) was encountered and hence `var' should be
treated as dynamically scoped when we run a `let'. Again, this only
applies to interpreted code.
> Also, the two closures are identical, yet add-hook isn't supposed to
> add duplicates.
No idea why that is, indeed.
To add&remove functions from hooks, it's much better to make sure you
actually pass the exact same object (not just one that should hopefully
be `equal').
Equality of functions is tricky business (both in theory and in practice).
Stefan
next prev parent reply other threads:[~2013-05-29 1:28 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-28 22:35 Unreferenced symbols in closures, and a problem with closures in minor modes Kelly Dean
2013-05-29 1:28 ` Stefan Monnier [this message]
-- strict thread matches above, loose matches on Subject: below --
2013-05-29 4:44 Kelly Dean
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=jwvppwabn47.fsf-monnier+gmane.emacs.help@gnu.org \
--to=monnier@iro.umontreal.ca \
--cc=help-gnu-emacs@gnu.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.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).