[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Lexical bindings (was Re: table.el)

From: Miles Bader
Subject: Re: Lexical bindings (was Re: table.el)
Date: 04 Dec 2001 08:57:27 +0900

address@hidden (Kim F. Storm) writes:
> I'm just trying to raise my concerns about the way it is being added
> to emacs, which IMO has a rather obscure semantics.

It's the same semantics as common-lisp, which is non-obscure enough for me!

> Does this code make sense, i.e. will x have lexical binding and y have
> dynamic binding in ....?

`lexical-binding' is not a "normal" variable.  That is (in the current
implementation, at least), its value is only noticed in a few places,
notably, during loading, by `eval-region' & friends, and by the
byte-compiler.  The only place it really make sense to set it is in a
file-header, or as a buffer-local variable to affect code evaluated in
that buffer.

The reason for this wierdness is because lexical binding is treated
very differently by the compiler and the interpreter.  While it's
reasonable for the interpreter to switch back and forth depending on
the runtime binding of a variable, it's much harder for the compiler!

The way that the interpreter currently decides whether to bind lexically
or not is by seeing if there's a current lexical environment; for this
reason, it's actually rather hard to define a `llet' that works
independently of other binding forms -- normal `let's nested inside
`llet' would see the lexical environment and decide that they should use
lexical binding too.

[ This could be fixed by having two separate variables, one holding the
environment, and one saying whether the default binding mode is lexical;
note that the latter can't be `lexical-binding' for several reasons:

 (1) Because it shouldn't be exposed to the user (see above), and

 (2) Because `lexical-binding' is buffer-local (so that it works
     correctly inside elisp source buffers), and getting the value of a
     buffer-local variables is less efficient than a normal variable, so
     I don't want to do so inside of often-used interpreter functions ]

> If so, we could add forms
>         (with-lexical-binding
>           ...)
>         (with-dynamic-binding
>           ...)

These are both easy to define.

Yo mama's so fat when she gets on an elevator it HAS to go down.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]