Re: Default lexical-binding to t

[Stefan Kangas]

Alan Mackenzie <acm@muc.de> writes:

>> Consider a simple example like this:
>
>>     (defun another-function ()
>>       (setq x 3))
>
>>     (defun foo ()
>>       (let ((x 1) (y 2))
>>         (another-function)
>>         (+ x y)))
>
>> This code is clearly bad, but regardless of that we get with dynbind,
>
>>     (foo) => 5
>
>> whereas with lexbind,
>
>>     (foo) => 3
>
> Yes.  Both results are clearly correct.

The question is not if Emacs correctly implements the dynbind and
lexbind semantics, but which of the two is more desirable.

In my view, lexbind provides the superior semantics for let-binding
non-special variables, assuming that we care about program correctness.
It completely eliminates an entire class of bugs.

You could perhaps argue that it's just up to the programmer to check
which variables are used in every function they call (and the functions
they call in turn, etc.), but that quickly gets impractical.  You could
also argue that rarely does this become an issue in practice, and that
might be true even.  It's also rare that people get killed in car
accidents, yet we still try to make roads and cars as safe as possible.

Consider also which semantics are better if we were to add concurrency
into the mix.  Having two concurrent processes competing about the same
`x` variable is not my idea of a good time.

>> Now, it's also true that theory tells us that lexbind should indeed
>> often lead to better performance, since the compiler can do
>> optimizations on such code that are hard or impractical with dynbind.
>
> But the overhead of having to construct closures for internal functions
> tends to counter other optimisations.

That might be true, but luckily we don't need to create closures for
internal functions everywhere.

BTW, if you see problems with lexbind in debugging, then I recommend
opening bug reports so we can discuss how to improve things.