GNU bug report logs - #14772
24.3; defvar and lexical-binding in interpreted elisp code

Previous Next

Full log

Message #8 received at 14772 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Jisang Yoo <jisang.yoo.ac+org <at> gmail.com>
Cc: 14772 <at> debbugs.gnu.org
Subject: Re: bug#14772: 24.3;
 defvar and lexical-binding in interpreted elisp code
Date: Wed, 03 Jul 2013 05:30:02 -0400

tags 14772 wontfix
thanks

> ;; two functions that are supposed to do the same thing
> (defun alice-multiplier-1 (foo)
>   (lambda (n) (* n foo)))
> (defun alice-multiplier-2 (num)
>   (let ((foo num))
>     (lambda (n) (* n foo))))

They're not supposed to be equivalent, because function arguments in
lexical-binding mode are documented as always being lexical, regardless
of any defvar.

> Output from emacs -q --load alice.el:

> (:R3 (10 20 30) :R4 (1000 2000 3000))


That's arguably a bug in the interpreter, indeed.   The byte-compiler
returns (:R3 (10 20 30) :R4 (10 20 30)) AFAIK.  The byte-compiler should
also point out the fact that there's a problem in the code: we let-bind
`foo' first and later on declare foo with defvar.

> suggests that (:R3 (1000 2000 3000) :R4 (1000 2000 3000)) should be
> the right output, which is the same as the CLIST output according to
> my test.

All three answers can be considered correct depending on what semantics
we want to give to the language (I happen to prefer the semantics we
currently get from the compiler).  The fact that we get different
results with the interpreter and with the compiler is a bug, but making
the interpreter follow the compiler's behavior would be difficult/costly
and making the compiler follow the interpreter's behavior is also
difficult/costly.

So I prefer to say that such code is "unsupported": you should always
place the defvar before let-binding the corresponding variable.


        Stefan

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.