GNU bug report logs - #3467
23.0.94; let + make-local-variable => let value made global

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 3467 in the body.
You can then email your comments to 3467 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Lennart Borgman <lennart.borgman <at> gmail.com>
To: emacs-pretest-bug <at> gnu.org
Subject: 23.0.94; let + make-local-variable => let value made global
Date: Thu, 4 Jun 2009 23:14:49 +0200

If you eval these lines

  (defvar w14 "global")
  (defvar w15 "global")
  (let ((w14 "let")
        (w15 "let"))
    (set (make-local-variable 'w14) "local")
    (message "w14 maybe let: in buffer=%S, global=%S" w14 (default-value 'w14))
    (message "w15 maybe let: in buffer=%S, global=%S" w15 (default-value 'w15)))
  (message "w14 top level: in buffer=%S, global=%S" w14 (default-value 'w14))
  (message "w15 top level: in buffer=%S, global=%S" w15 (default-value 'w15))

the output will be

  w14 maybe let: in buffer="local", global="let"
  w15 maybe let: in buffer="let", global="let"
  w14 top level: in buffer="global", global="let"
  w15 top level: in buffer="global", global="global"

All values here except w14 global value on next last line are arguably
correct. The last value of w14 should be "global", not "let".

It looks like perhaps the call to (make-local-variable w14) does not
mark the "global let" value of w14 as let bound (or removes that
mark).



In GNU Emacs 23.0.94.1 (i386-mingw-nt5.1.2600)
 of 2009-05-23
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (3.4) --no-opt --cflags
-Ic:/g/include -fno-crossjumping'

Message #10 received at 3467 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Lennart Borgman <lennart.borgman <at> gmail.com>
To: 3467 <at> debbugs.gnu.org
Subject: Re: bug#3467: 23.0.94; let + make-local-variable => let value made 
	global
Date: Fri, 5 Jun 2009 16:21:37 +0200

On Thu, Jun 4, 2009 at 11:14 PM, Lennart
Borgman<lennart.borgman <at> gmail.com> wrote:
> If you eval these lines
>
>  (defvar w14 "global")
>  (defvar w15 "global")
>  (let ((w14 "let")
>        (w15 "let"))
>    (set (make-local-variable 'w14) "local")
>    (message "w14 maybe let: in buffer=%S, global=%S" w14 (default-value 'w14))
>    (message "w15 maybe let: in buffer=%S, global=%S" w15 (default-value 'w15)))
>  (message "w14 top level: in buffer=%S, global=%S" w14 (default-value 'w14))
>  (message "w15 top level: in buffer=%S, global=%S" w15 (default-value 'w15))
>
> the output will be
>
>  w14 maybe let: in buffer="local", global="let"
>  w15 maybe let: in buffer="let", global="let"
>  w14 top level: in buffer="global", global="let"
>  w15 top level: in buffer="global", global="global"
>
> All values here except w14 global value on next last line are arguably
> correct. The last value of w14 should be "global", not "let".
>
> It looks like perhaps the call to (make-local-variable w14) does not
> mark the "global let" value of w14 as let bound (or removes that
> mark).


I think the semantics of let, make-variable-buffer-local and buffer
local variables must be examined a bit to clarify this:

I think let should preserve "buffer localness" otherwise it might do
something quite different from what a user probably expect.

Fortunately this as far as I can see requires only a change in Flet.
After Fprogn and before calling unbound_to the variable values must be
reset to those matching the buffer and frame localness before let.

spec_bind has saved the buffer and frame localness just before Fprogn
so I guess one can compare with what is saved there.


However no one would want me to write the C code for this... ;-) -
Someone who is better than me at that should preferrably do it.


(BTW: gmail does not automatically enter the reply address when I make
a reply to the original bug mail. Is that a bug in gmail?)

Message #15 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Lennart Borgman <lennart.borgman <at> gmail.com>
Cc: 3467 <at> debbugs.gnu.org, emacs-pretest-bug <at> gnu.org
Subject: Re: bug#3467: 23.0.94; let + make-local-variable => let value made global
Date: Fri, 05 Jun 2009 10:36:57 -0400

> If you eval these lines
>   (defvar w14 "global")
>   (defvar w15 "global")
>   (let ((w14 "let")
>         (w15 "let"))
>     (set (make-local-variable 'w14) "local")
>     (message "w14 maybe let: in buffer=%S, global=%S" w14 (default-value 'w14))
>     (message "w15 maybe let: in buffer=%S, global=%S" w15 (default-value 'w15)))
>   (message "w14 top level: in buffer=%S, global=%S" w14 (default-value 'w14))
>   (message "w15 top level: in buffer=%S, global=%S" w15 (default-value 'w15))

> the output will be

>   w14 maybe let: in buffer="local", global="let"
>   w15 maybe let: in buffer="let", global="let"
>   w14 top level: in buffer="global", global="let"
>   w15 top level: in buffer="global", global="global"

> All values here except w14 global value on next last line are arguably
> correct. The last value of w14 should be "global", not "let".

> It looks like perhaps the call to (make-local-variable w14) does not
> mark the "global let" value of w14 as let bound (or removes that
> mark).

Given the way let-binding and buffer-local bindings are currently
implemented, it's difficult to make it work correctly in all corner
cases, and even more so without slowing down the common case.
So don't hold your breath.


        Stefan

Message #25 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Lennart Borgman <lennart.borgman <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 3467 <at> debbugs.gnu.org, emacs-pretest-bug <at> gnu.org
Subject: Re: bug#3467: 23.0.94; let + make-local-variable => let value made 
	global
Date: Fri, 5 Jun 2009 17:04:01 +0200

On Fri, Jun 5, 2009 at 4:36 PM, Stefan Monnier<monnier <at> iro.umontreal.ca> wrote:
>> If you eval these lines
>>   (defvar w14 "global")
>>   (defvar w15 "global")
>>   (let ((w14 "let")
>>         (w15 "let"))
>>     (set (make-local-variable 'w14) "local")
>>     (message "w14 maybe let: in buffer=%S, global=%S" w14 (default-value 'w14))
>>     (message "w15 maybe let: in buffer=%S, global=%S" w15 (default-value 'w15)))
>>   (message "w14 top level: in buffer=%S, global=%S" w14 (default-value 'w14))
>>   (message "w15 top level: in buffer=%S, global=%S" w15 (default-value 'w15))
>
>> the output will be
>
>>   w14 maybe let: in buffer="local", global="let"
>>   w15 maybe let: in buffer="let", global="let"
>>   w14 top level: in buffer="global", global="let"
>>   w15 top level: in buffer="global", global="global"
>
>> All values here except w14 global value on next last line are arguably
>> correct. The last value of w14 should be "global", not "let".
>
>> It looks like perhaps the call to (make-local-variable w14) does not
>> mark the "global let" value of w14 as let bound (or removes that
>> mark).
>
> Given the way let-binding and buffer-local bindings are currently
> implemented, it's difficult to make it work correctly in all corner
> cases, and even more so without slowing down the common case.
> So don't hold your breath.

I gave a suggestion in the next message for how to implement this:
Check buffer and frame localness before unbind_to in Flet. Would that
really be expensive?

Message #35 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Lennart Borgman <lennart.borgman <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 3467 <at> debbugs.gnu.org, emacs-pretest-bug <at> gnu.org
Subject: Re: bug#3467: 23.0.94; let + make-local-variable => let value made 
	global
Date: Sat, 6 Jun 2009 00:48:16 +0200

On Fri, Jun 5, 2009 at 5:04 PM, Lennart
Borgman<lennart.borgman <at> gmail.com> wrote:
> On Fri, Jun 5, 2009 at 4:36 PM, Stefan Monnier<monnier <at> iro.umontreal.ca> wrote:
>>> If you eval these lines
>>>   (defvar w14 "global")
>>>   (defvar w15 "global")
>>>   (let ((w14 "let")
>>>         (w15 "let"))
>>>     (set (make-local-variable 'w14) "local")
>>>     (message "w14 maybe let: in buffer=%S, global=%S" w14 (default-value 'w14))
>>>     (message "w15 maybe let: in buffer=%S, global=%S" w15 (default-value 'w15)))
>>>   (message "w14 top level: in buffer=%S, global=%S" w14 (default-value 'w14))
>>>   (message "w15 top level: in buffer=%S, global=%S" w15 (default-value 'w15))
>>
>>> the output will be
>>
>>>   w14 maybe let: in buffer="local", global="let"
>>>   w15 maybe let: in buffer="let", global="let"
>>>   w14 top level: in buffer="global", global="let"
>>>   w15 top level: in buffer="global", global="global"
>>
>>> All values here except w14 global value on next last line are arguably
>>> correct. The last value of w14 should be "global", not "let".
>>
>>> It looks like perhaps the call to (make-local-variable w14) does not
>>> mark the "global let" value of w14 as let bound (or removes that
>>> mark).
>>
>> Given the way let-binding and buffer-local bindings are currently
>> implemented, it's difficult to make it work correctly in all corner
>> cases, and even more so without slowing down the common case.
>> So don't hold your breath.
>
> I gave a suggestion in the next message for how to implement this:
> Check buffer and frame localness before unbind_to in Flet. Would that
> really be expensive?


Sigh, and my suggestion was of course unnecessary stupid. What is
needed is of course to record values and frame+buffer localness and
dito values and reset them. Nothing less than this will ever work
correctly, or?

And does not this apply to all uses of specbind + unbind_to?

Can it be sufficient to just change specbind and unbind_to? Is there
anything else that will be affected by changes in the specbind stack?
Since info about buffer+frame is alwas needed should specbinding be
changed to the below form?

struct specbinding
  {
    Lisp_Object symbol;
    Lisp_Object old_value;
    Lisp_Object old_buffer_value;
    Lisp_Object old_frame_value;
    specbinding_func func;
    Lisp_Object unused;		/* Dividing by 16 is faster than by 12 */
    Lisp_Object unused;
    Lisp_Object unused;
  };

Is this structure used by other functions than specbind and unbind_to?

Message #45 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Lennart Borgman <lennart.borgman <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 3467 <at> debbugs.gnu.org, emacs-pretest-bug <at> gnu.org
Subject: Re: bug#3467: 23.0.94; let + make-local-variable => let value made 
	global
Date: Sat, 6 Jun 2009 01:08:17 +0200

On Sat, Jun 6, 2009 at 12:48 AM, Lennart
Borgman<lennart.borgman <at> gmail.com> wrote:
>
> Sigh, and my suggestion was of course unnecessary stupid. What is
> needed is of course to record values and frame+buffer localness and
> dito values and reset them. Nothing less than this will ever work
> correctly, or?
>
> And does not this apply to all uses of specbind + unbind_to?
>
> Can it be sufficient to just change specbind and unbind_to? Is there
> anything else that will be affected by changes in the specbind stack?
> Since info about buffer+frame is alwas needed should specbinding be
> changed to the below form?
>
> struct specbinding
>  {
>    Lisp_Object symbol;
>    Lisp_Object old_value;
>    Lisp_Object old_buffer_value;
>    Lisp_Object old_frame_value;
>    specbinding_func func;
>    Lisp_Object unused;         /* Dividing by 16 is faster than by 12 */
>    Lisp_Object unused;
>    Lisp_Object unused;
>  };
>
> Is this structure used by other functions than specbind and unbind_to?

... and defvar ... but I do not think there are any more uses of
specbinding's structure. Or does some allocation need to change?

Message #55 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Lennart Borgman <lennart.borgman <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 3467 <at> debbugs.gnu.org, emacs-pretest-bug <at> gnu.org
Subject: Re: bug#3467: 23.0.94; let + make-local-variable => let value made 
	global
Date: Sat, 6 Jun 2009 01:32:04 +0200

On Sat, Jun 6, 2009 at 1:08 AM, Lennart
Borgman<lennart.borgman <at> gmail.com> wrote:
>
> ... and defvar ... but I do not think there are any more uses of
> specbinding's structure. Or does some allocation need to change?

... and let_shadows_buffer_binding_p  which is a bit lonely without
its sister let_shadows_frame_binding_p (or is such a sister not of any
importance? I do not really know about frame local variables, but
specbind seems to know) ...

Message #65 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Richard Stallman <rms <at> gnu.org>
To: Lennart Borgman <lennart.borgman <at> gmail.com>,
        3467 <at> debbugs.gnu.org
Cc: emacs-pretest-bug <at> gnu.org
Subject: Re: bug#3467: 23.0.94;
	let + make-local-variable => let value made global
Date: Sat, 06 Jun 2009 16:05:26 -0400

I think this is a use case that should be avoided.
Maybe it can be made to work "right", but if that's difficult,
I'd rather tell people not to do it.

Message #75 received at 3467 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Lennart Borgman <lennart.borgman <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 3467 <at> debbugs.gnu.org
Subject: Re: bug#3467: 23.0.94; let + make-local-variable => let value made 
	global
Date: Sat, 6 Jun 2009 22:11:21 +0200

[Message part 1 (text/plain, inline)]

On Sat, Jun 6, 2009 at 12:48 AM, Lennart
Borgman<lennart.borgman <at> gmail.com> wrote:
>
> Sigh, and my suggestion was of course unnecessary stupid. What is
> needed is of course to record values and frame+buffer localness and
> dito values and reset them. Nothing less than this will ever work
> correctly, or?
>
> And does not this apply to all uses of specbind + unbind_to?
>
> Can it be sufficient to just change specbind and unbind_to? Is there
> anything else that will be affected by changes in the specbind stack?
> Since info about buffer+frame is alwas needed should specbinding be
> changed to the below form?
>
> struct specbinding
>  {
>    Lisp_Object symbol;
>    Lisp_Object old_value;
>    Lisp_Object old_buffer_value;
>    Lisp_Object old_frame_value;
>    specbinding_func func;
>    Lisp_Object unused;         /* Dividing by 16 is faster than by 12 */
>    Lisp_Object unused;
>    Lisp_Object unused;
>  };

Here is a bit modified suggestion and some code where I try to
implement it. Please notice that I have not tested the code. It is
very possible that I have misunderstood something so please look at
the code.

struct specbinding
  {
    Lisp_Object symbol;
    Lisp_Object old_value;
    specbinding_func func;
    // total 8 fields
    Lisp_Object need_test_local;
    Lisp_Object old_buffer;
    Lisp_Object old_buffer_value;
    Lisp_Object old_frame;
    Lisp_Object old_frame_value;
    //Lisp_Object unused;		/* Dividing by 16 is faster than by 12 */
  };

[eval.diff (application/octet-stream, attachment)]

Message #80 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Lennart Borgman <lennart.borgman <at> gmail.com>
To: rms <at> gnu.org
Cc: 3467 <at> debbugs.gnu.org, emacs-pretest-bug <at> gnu.org
Subject: Re: bug#3467: 23.0.94; let + make-local-variable => let value made 
	global
Date: Sat, 6 Jun 2009 22:13:57 +0200

On Sat, Jun 6, 2009 at 10:05 PM, Richard Stallman<rms <at> gnu.org> wrote:
> I think this is a use case that should be avoided.
> Maybe it can be made to work "right", but if that's difficult,
> I'd rather tell people not to do it.

I can't see how it can be avoided. Whenever make-local-variable or
kill-local-variable this problem can occur (if the variable happen to
be let bound of course).

Message #90 received at 3467 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Lennart Borgman <lennart.borgman <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 3467 <at> debbugs.gnu.org
Subject: Re: bug#3467: 23.0.94; let + make-local-variable => let value made 
	global
Date: Sun, 7 Jun 2009 03:11:23 +0200

Rethinking. Everything is wrong in my solution and suggestion. Coming back.


On Sat, Jun 6, 2009 at 10:11 PM, Lennart
Borgman<lennart.borgman <at> gmail.com> wrote:
> On Sat, Jun 6, 2009 at 12:48 AM, Lennart
> Borgman<lennart.borgman <at> gmail.com> wrote:
>>
>> Sigh, and my suggestion was of course unnecessary stupid. What is
>> needed is of course to record values and frame+buffer localness and
>> dito values and reset them. Nothing less than this will ever work
>> correctly, or?
>>
>> And does not this apply to all uses of specbind + unbind_to?
>>
>> Can it be sufficient to just change specbind and unbind_to? Is there
>> anything else that will be affected by changes in the specbind stack?
>> Since info about buffer+frame is alwas needed should specbinding be
>> changed to the below form?
>>
>> struct specbinding
>>  {
>>    Lisp_Object symbol;
>>    Lisp_Object old_value;
>>    Lisp_Object old_buffer_value;
>>    Lisp_Object old_frame_value;
>>    specbinding_func func;
>>    Lisp_Object unused;         /* Dividing by 16 is faster than by 12 */
>>    Lisp_Object unused;
>>    Lisp_Object unused;
>>  };
>
> Here is a bit modified suggestion and some code where I try to
> implement it. Please notice that I have not tested the code. It is
> very possible that I have misunderstood something so please look at
> the code.
>
> struct specbinding
>  {
>    Lisp_Object symbol;
>    Lisp_Object old_value;
>    specbinding_func func;
>    // total 8 fields
>    Lisp_Object need_test_local;
>    Lisp_Object old_buffer;
>    Lisp_Object old_buffer_value;
>    Lisp_Object old_frame;
>    Lisp_Object old_frame_value;
>    //Lisp_Object unused;               /* Dividing by 16 is faster than by 12 */
>  };
>

Message #95 received at 3467 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Lennart Borgman <lennart.borgman <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 3467 <at> debbugs.gnu.org
Subject: Re: bug#3467: 23.0.94; let + make-local-variable => let value made 
	global
Date: Sat, 13 Jun 2009 00:24:43 +0200

[Message part 1 (text/plain, inline)]

On Sun, Jun 7, 2009 at 3:11 AM, Lennart
Borgman<lennart.borgman <at> gmail.com> wrote:
> Rethinking. Everything is wrong in my solution and suggestion. Coming back.


Ok, here is what I believe is a reasonable solution.

The first problem is that the semantics of let,
make-variable-buffer-local etc are not clearly defined. I suggest the
following semantics (instead of the one I proposed before):

- When (let ...) shadows a variable it is exactly this variable (ie
default or buffer local version) that should be revived after (let
...).

- No buffer local variables should be deleted or created by the
reviving of the shadowed variables after the (let ...) clause.

- More exactly: if the variable is buffer local in the current buffer
before (let ..) it is the buffer local variable in that buffer that
should be revived. If it does not exist after (let..) nothing should
be done.

- And if a shadowed variable have been made buffer local during the
let binding then it is still the default value that should be revived.
The buffer local value should in this case not be changed after the
(let ..) clause.

I think with this semantics everything will be nearly as fast as
before and there will be no such surprises as shown in this bug. What
do others think?


I have made a patch for this with some comments and questions. I have
included this in my patched version of Emacs+EmacsW32 and have been
using it myself for a couple of days without any problems.

However please review this carefully and especially what I have called
/* Case 1 in specbind */ in unbind_to.

[eval-bug3467.diff (application/octet-stream, attachment)]

Message #102 received at 3467 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Lennart Borgman <lennart.borgman <at> gmail.com>
Cc: 3467 <at> debbugs.gnu.org
Subject: Re: bug#3467: 23.0.94; let + make-local-variable => let value made
Date: Sat, 27 Jun 2009 02:24:00 +0200

> The first problem is that the semantics of let,
> make-variable-buffer-local etc are not clearly defined. I suggest the
> following semantics (instead of the one I proposed before):

That's the intuitive semantics, indeed.

> I have made a patch for this with some comments and questions. I have
> included this in my patched version of Emacs+EmacsW32 and have been
> using it myself for a couple of days without any problems.

- NULL is equal to 0 by definition.
- Why do you check

             if (!NILP (Flocal_variable_p (symbol, where)) ||
                 !NILP (Flocal_variable_if_set_p (symbol, where)))
  i.s.o.
             if (!NILP (Flocal_variable_p (symbol, where)))
  That looks wrong since it would undo a kill-local-variable that was
  performed within the let.
- Regarding "Case 1 in specbind", I have (in my local changes)
  completely rewritten the variable-binding code so as not to use
  special MISCP values.  I find it makes the code clearer, tho maybe
  others will disagree.  I intend to install it in the trunk for 23.2
  and it of course conflicts completely with your patch ;-)
  If you want, I can try and extract the corresponding patch and send it
  to you.


        Stefan

Previous Next

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