RE: DynamicBindingVsLexicalBinding

[Drew Adams <drew.adams@oracle.com>]

> > Yes.  Which is especially important for a heavily interactive and
> > customizable program such as Emacs.  Emacs users extend and
> > otherwise modify or adapt the source code, and they do so sometimes
> > on the fly and interactively.
> 
> I don't think this is an advantage of dynamic binding; it's just an
> advantage of having lots of configuration options.

Which are dynamically bound variables.  Perhaps you are not as lexical
as you think. ;-)

Do you mean that you are OK with assigning values to such global,
dynamically bound variables at startup time, and you are OK with a
user changing their values interactively anytime (e.g. using Customize),
but you are not OK with code let-binding global, dynamically bound
variables?  Assignment is OK by you, but not let-binding?

> I've certainly used the feature that Kai likes, but mostly it has
> been to hack around code which I do not control or do not want to
> change.  Nowadays, in general, I would want to advice code instead.

http://www.gnu.org/software/emacs/emacs-paper.html#SEC17  (Richard
Stallman, 1981), including:

"Formal Parameters Cannot Replace Dynamic Scope

 Some language designers believe that dynamic binding should be avoided,
 and explicit argument passing should be used instead. Imagine that
 function A binds the variable FOO, and calls the function B, which
 calls the function C, and C uses the value of FOO. Supposedly A should
 pass the value as an argument to B, which should pass it as an argument
 to C. 

 This cannot be done in an extensible system, however, because the author
 of the system cannot know what all the parameters will be. Imagine that
 the functions A and C are part of a user extension, while B is part of
 the standard system. The variable FOO does not exist in the standard
 system; it is part of the extension. To use explicit argument passing
 would require adding a new argument to B, which means rewriting B and
 everything that calls B. In the most common case, B is the editor
 command dispatcher loop, which is called from an awful number of places. 

 What's worse, C must also be passed an additional argument. B doesn't
 refer to C by name (C did not exist when B was written). It probably
 finds a pointer to C in the command dispatch table. This means that
 the same call which sometimes calls C might equally well call any
 editor command definition. So all the editing commands must be
 rewritten to accept and ignore the additional argument. By now, none
 of the original system is left!"