* Unreferenced symbols in closures, and a problem with closures in minor modes
@ 2013-05-28 22:35 Kelly Dean
2013-05-29 1:28 ` Stefan Monnier
0 siblings, 1 reply; 3+ messages in thread
From: Kelly Dean @ 2013-05-28 22:35 UTC (permalink / raw)
To: help-gnu-emacs
(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? And why produce a closure with an empty environment, instead of just a lambda form?
And I have a problem with unwanted closures in minor modes:
(defvar foo-hook nil)
(define-minor-mode bar "Bar" nil " Bar" nil
(if bar (add-hook 'foo-hook (lambda () (bar 0)) nil t)
(remove-hook 'foo-hook (lambda () (bar 0)) t)))
M-x bar RET C-h v foo-hook RET, and I get:
foo-hook's value is ((closure
((last-message)
(arg . toggle)
t)
nil
(bar 0))
t)
Which won't be removed when foo-hook runs, because arg will be 0, not 'toggle. I tried to thwart the closure like this:
(defvar foo2-hook nil)
(define-minor-mode bar2 "Bar2" nil " Bar2" nil
(if bar2 (add-hook 'foo2-hook (let ((arg 0)) (lambda () (bar2 0))) nil t)
(remove-hook 'foo2-hook (let ((arg 0)) (lambda () (bar2 0))) t)))
M-x bar2 RET C-h v foo2-hook RET, and I get:
foo2-hook's value is ((closure
((arg . 0)
(last-message)
(arg . toggle)
t)
nil
(bar2 0))
t)
Argh! Surely this is a misfeature?
Also I don't know why last-message is there, but at least it doesn't interfere.
On a previous experiment that I can't reproduce, involving several additions and removals, I got:
Value: ((closure
((last-message)
(arg . 1)
i t)
nil
(bar 0))
(closure
((last-message)
(arg . 1)
i t)
nil
(bar 0))
t)
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.
Also, the two closures are identical, yet add-hook isn't supposed to add duplicates.
Help?
^ permalink raw reply [flat|nested] 3+ messages in thread* Re: Unreferenced symbols in closures, and a problem with closures in minor modes
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
0 siblings, 0 replies; 3+ messages in thread
From: Stefan Monnier @ 2013-05-29 1:28 UTC (permalink / raw)
To: help-gnu-emacs
> (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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Unreferenced symbols in closures, and a problem with closures in minor modes
@ 2013-05-29 4:44 Kelly Dean
0 siblings, 0 replies; 3+ messages in thread
From: Kelly Dean @ 2013-05-29 4:44 UTC (permalink / raw)
To: help-gnu-emacs
Stefan Monnier wrote:
[...]
> 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').
Thanks for the fast help and explanations. Per your suggestion I'm avoiding both the equality testing of functions and the unwanted lexical environment this way:
(defun bar-off () (bar 0))
(define-minor-mode bar "Bar" nil " Bar" nil
(if bar (add-hook 'foo-hook 'bar-off nil t)
(remove-hook 'foo-hook 'bar-off t)))
although I was tempted to do it this way just to spite the interpreter :-)
(setq bar-off (lambda () (bar 0)))
(define-minor-mode bar "Bar" nil " Bar" nil
(if bar (add-hook 'foo-hook (symbol-value 'bar-off) nil t)
(remove-hook 'foo-hook (symbol-value 'bar-off) t)))
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2013-05-29 4:44 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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
-- strict thread matches above, loose matches on Subject: below --
2013-05-29 4:44 Kelly Dean
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).