bug#8711: 24.0.50; binding _ to unused values with lexical-binding

[Stefan Monnier]

>> I think the same problem happens with dotimes/dolist using the old
>> definition: the loop vars `key' and `value' are let-bound outside the
>> loop and then setq'd at each loop iteration (it's this setq that causes
>> them to be "not left unused").  This was OK for the dynamic scoping case
>> because let-binding is significantly more costly than setq, but it is
>> not right for the lexical scoping case where the cost of let is not
>> higher than `setq' and where the semantic is actually then wrong:
>> e.g. if you "collect (lambda () value)" the current code ends up
>> returning a list of functions that all return the last `value', rather
>> than a list of functions that each return one of the `values' in
>> the alist.
> BTW, is there a good reason why we can't disallow setq on closed over
> variables in Elisp?

Yes and no: technically, we could, of course, but I'm not sure that's
worth the trouble.  I'm in favor of pure languages (e.g. I've local
changes that make Emacs strings immutable, often install changes that
reduce the use of setq, ...) but realistically Emacs Lisp won't get rid
of setq any time soon.  Now, why single out setq on closed over variables?
Note that currently closures are used internally a lot more often than
you'd think, since every condition-case, unwind-protect, and catch
makes its body and branches into closures.  Also it's common for
lambda arguments to mapcar and mapc to use setq on some closed over
variable used a sort of accumulator.

> That kind of mutability seems like a bad idea in a
> concurrent world.

Emacs has a crapload of global state, so we won't be able to wiggle
around global mutability problems.  Maybe every bit helps, but I'm very
much unconvinced.

> Closures are a new feature so we could make a conscious decision not
> to introduce the problematic mutable variables.

But I also want it to be as easy as possible to turn valid dynbind Elisp
code into valid lexbind code, so any additional restriction needs a very
good justification.


        Stefan