lexical-binding rationale?

lexical-binding rationale?

[Dave Abrahams]

I'm sure this has been discussed to death, so please feel free to
respond with a link, but... can anyone point me to a rationale for
dynamically altering such a fundamental language behavior on the basis
of a variable's value?

Thanks,

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com

Re: lexical-binding rationale?

[Alan Mackenzie]

On Thu, Jan 12, 2012 at 11:47:35AM -0500, Dave Abrahams wrote:

Request for clarification:

> I'm sure this has been discussed to death, so please feel free to
> respond with a link, but... can anyone point me to a rationale for
> dynamically altering such a fundamental language behavior on the basis
> of a variable's value?

What, exactly does "dynamically altering" mean?
What is the "fundamental language behaviour" which is being/to be
  dynamically altered.
What precise relationship has been abstracted to "on the basis of"?
Which "variable's value" is meant here.

Or, more succinctly, what the heck are you going on about?

> Thanks,

> -- 
> Dave Abrahams

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: lexical-binding rationale?

[Alan Mackenzie]

On Thu, Jan 12, 2012 at 01:50:33PM -0500, Dave Abrahams wrote:

> on Thu Jan 12 2012, Alan Mackenzie <acm-AT-muc.de> wrote:

> > On Thu, Jan 12, 2012 at 11:47:35AM -0500, Dave Abrahams wrote:

> > Request for clarification:

> >> I'm sure this has been discussed to death, so please feel free to
> >> respond with a link, but... can anyone point me to a rationale for
> >> dynamically altering such a fundamental language behavior on the
> >> basis of a variable's value?

> > What, exactly does "dynamically altering" mean?

> Sorry, that's a very dangerous term developed in secret at the
> U.S. Department of Redundancy Department.

> Let's just say, "altering"

> > What is the "fundamental language behaviour" which is being/to be
> > dynamically altered.  
> > What precise relationship has been abstracted to "on the basis of"?
> > Which "variable's value" is meant here.

> My understanding is that Emacs is using a buffer-local variable called
> `lexical-binding' to determine whether variable bindings shall be
> dynamic or lexical.

OK, got you now!  Thanks.

> -- 
> Dave Abrahams

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: lexical-binding rationale?

[Dave Abrahams]

on Thu Jan 12 2012, Alan Mackenzie <acm-AT-muc.de> wrote:

> On Thu, Jan 12, 2012 at 11:47:35AM -0500, Dave Abrahams wrote:
>
> Request for clarification:
>
>> I'm sure this has been discussed to death, so please feel free to
>> respond with a link, but... can anyone point me to a rationale for
>> dynamically altering such a fundamental language behavior on the basis
>> of a variable's value?
>
> What, exactly does "dynamically altering" mean?

Sorry, that's a very dangerous term developed in secret at the
U.S. Department of Redundancy Department.

Let's just say, "altering"

> What is the "fundamental language behaviour" which is being/to be
> dynamically altered.  
> What precise relationship has been abstracted to "on the basis of"?
> Which "variable's value" is meant here.

My understanding is that Emacs is using a buffer-local variable called
`lexical-binding' to determine whether variable bindings shall be
dynamic or lexical.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com

Re: lexical-binding rationale?

[Glenn Morris]

Dave Abrahams wrote:

> I'm sure this has been discussed to death, so please feel free to
> respond with a link, but... can anyone point me to a rationale for
> dynamically altering such a fundamental language behavior on the basis
> of a variable's value?

It's easy to use on a per-file basis, and in the majority of cases
allows the source to be transparently backwards compatible with
older/other versions of Emacs; so why not. Since it's a fait accompli,
discussing alternative ways it might have been done are only going to be
of academic interest.

I never did get an answer to my question about whether the setting HAS
to go in the first line of the file though. I still don't know.

http://debbugs.gnu.org/cgi/bugreport.cgi?bug=8610#8

Re: lexical-binding rationale?

[Stefan Monnier]

>> I'm sure this has been discussed to death, so please feel free to
>> respond with a link, but... can anyone point me to a rationale for
>> dynamically altering such a fundamental language behavior on the basis
>> of a variable's value?
> It's easy to use on a per-file basis, and in the majority of cases
> allows the source to be transparently backwards compatible with
> older/other versions of Emacs; so why not. Since it's a fait accompli,
> discussing alternative ways it might have been done are only going to be
> of academic interest.
> I never did get an answer to my question about whether the setting HAS
> to go in the first line of the file though. I still don't know.
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=8610#8

The intention is that it should work like any other file-local setting
so it can go in the end as well, but I haven't checked that
lisp_file_lexically_bound_p handles that cases correctly.  If it
doesn't, then the file would be mis-handled when loading it uncompiled
(which is the only case where lisp_file_lexically_bound_p is used).


        Stefan

Re: lexical-binding rationale?

[Richard Stallman]

    I'm sure this has been discussed to death, so please feel free to
    respond with a link, but... can anyone point me to a rationale for
    dynamically altering such a fundamental language behavior on the basis
    of a variable's value?

It has to be specified somehow, so how would you suggest?

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

Re: lexical-binding rationale?

[Glenn Morris]

Stefan Monnier wrote:

> The intention is that it should work like any other file-local setting
> so it can go in the end as well, but I haven't checked that
> lisp_file_lexically_bound_p handles that cases correctly.

Just from looking at it, it sure looks like it doesn't.

Re: lexical-binding rationale?

[Dave Abrahams]

on Fri Jan 13 2012, Richard Stallman <rms-AT-gnu.org> wrote:

>     I'm sure this has been discussed to death, so please feel free to
>     respond with a link, but... can anyone point me to a rationale for
>     dynamically altering such a fundamental language behavior on the basis
>     of a variable's value?
>
> It has to be specified somehow, so how would you suggest?

Maybe it's fine the way it is.  My impression was that it was going to
be affected by a local variable setting in the current buffer, but IIUC
it is a local variable setting in the buffer from which elisp is being
read (? this isn't entirely clear—and it should be—from the
documentation).

If so, that gives me less of a cause for worry.  My initial reaction
when I heard about this was that we should have a set of
functions/macros for lexical binding, e.g. (lex-let ((a b)(c d)) (body))
but then, as I say, I may have misunderstood what was happening.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com

Re: lexical-binding rationale?

[Stefan Monnier]

> Maybe it's fine the way it is.  My impression was that it was going to
> be affected by a local variable setting in the current buffer, but IIUC
> it is a local variable setting in the buffer from which elisp is being
> read (? this isn't entirely clear—and it should be—from the
> documentation).

Right.  The variable is looked up when calling `eval', not when
processing let-bindings.  So indeed it is the value in the buffer from
which the code was `read' that is important, rather than the value in
the buffer that happens to be current when a new binding is created.


        Stefan

Re: lexical-binding rationale?

[Dave Abrahams]

on Fri Jan 13 2012, Stefan Monnier <monnier-AT-iro.umontreal.ca> wrote:

>> Maybe it's fine the way it is.  My impression was that it was going to
>> be affected by a local variable setting in the current buffer, but IIUC
>> it is a local variable setting in the buffer from which elisp is being
>> read (? this isn't entirely clear—and it should be—from the
>> documentation).
>
> Right.  The variable is looked up when calling `eval', not when
> processing let-bindings.  So indeed it is the value in the buffer from
> which the code was `read' that is important, rather than the value in
> the buffer that happens to be current when a new binding is created.

IMO it's a documentation bug that I had to ask that question.  Could
someone please fix that?

Thanks,

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com

Re: lexical-binding rationale?

[Ted Zlatanov]

On Fri, 13 Jan 2012 10:28:53 -0500 Dave Abrahams <dave@boostpro.com> wrote: 

DA> My initial reaction when I heard about this was that we should have
DA> a set of functions/macros for lexical binding, e.g. (lex-let ((a
DA> b)(c d)) (body)) but then, as I say, I may have misunderstood what
DA> was happening.

Wait, you know about `lexical-let', right?

Ted

Re: lexical-binding rationale?

[Stefan Monnier]

>> The intention is that it should work like any other file-local setting
>> so it can go in the end as well, but I haven't checked that
>> lisp_file_lexically_bound_p handles that cases correctly.
> Just from looking at it, it sure looks like it doesn't.

Hmm... indeed!

I guess lisp_file_lexically_bound_p should largely be rewritten by
moving it to load-with-code-conversion/load-source-file-function.
This said, now that I see the code it's clear that if we care about the
performance of loading .el (i.e. uncompiled) files, then we should force
lexical-binding to be on the first line.  Of course, currently it looks
like we don't care about this performance (that's probably the reason
why people have started to see a real speed up when compiling their
.emacs file), but if we want to be able to change our minds, we'd better
impose the restriction right away because afterwards will be too late.


        Stefan