Hm, this doesn't mention support for lexical closures (not turned on by default, of course) which supposedly has been merged into the master branch. I sure hope this will make it into the release.
Ultimately, this feature isn't as important as everyone thinks it is. One thing that's great about Emacs is that it's easy to extend in ways that were not intended. When everyone starts doing Java-style enforced privacy, that's one less way to extend Emacs. The whole system becomes more rigid with no actual benefit. (When you are writing a server-side Java application, it's worth the increase in reliability to be able to know that your local variables are in a well-defined state; not knowing that leads to subtle and annoying bugs. But when you are writing a text editor that has a programmer sitting in front of it, interacting with it for every second that it is alive, this becomes significantly less important. As a thought experiment, I tried writing an Emacs extension as though it were a Java or CL program. It sucked.)
Ultimately, a closure is a (function . state) cons cell. Emacs doesn't need desperately need any new primitive to handle this; it's easy to pass in state to a function that needs it. So while I will certainly take advantage of closures when they become available, I'm not excited like a little kid waiting to open his Christmas. It's nice, but not Earth-shattering. And lexical variable binding comes with significant extensibility downsides when misused.
And lexical variable binding comes with significant extensibility downsides when misused.
It sure does. Consider the draconian module system in Node.js that wraps all your code inside a lambda sandwich, shutting it away completely, and then forcing you to petition for access to it on a case-by-case basis. (The justification for this apparently being nothing more sophisticated than "But encapsulation is good.")
This is the programming equivalent of bureaucracy stifling innovation. It is particularly disastrous for writing new tools, which of course is an area where Emacs shines.
If something is not easy to extend in ways that were not intended, it is not easy to extend.
Ultimately, a closure is a (function . state) cons cell. Emacs doesn't need desperately need any new primitive to handle this; it's easy to pass in state to a function that needs it. So while I will certainly take advantage of closures when they become available, I'm not excited like a little kid waiting to open his Christmas. It's nice, but not Earth-shattering. And lexical variable binding comes with significant extensibility downsides when misused.