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

Previous Next

Full log

View this message in rfc822 format

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: 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?

Previous Next

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