On 02/13/2015 07:49 AM, Eli Zaretskii wrote: >> Date: Fri, 13 Feb 2015 07:06:17 -0800 >> From: Daniel Colascione >> CC: eggert@cs.ucla.edu, emacs-devel@gnu.org >> >> This way, instead of loaded modules needing to track Emacs' historically >> unstable internal data structures, elisp needs to track module ABIs, > > How's that better? That's the same problem in the opposite direction, > only much worse, since the modules out there are not under our control > at all. The risk isn't symmetric: 1) Shared libraries traditionally expose stable ABIs; when ABIs change incompatibly, libraries change sonames. Shared libraries need stable ABIs whether or not Emacs loads them: they're linked into other programs and aren't necessarily rebuilt at the same time as their dependencies. The Emacs core has never had a stable ABI, and creating one would constrain our optimization opportunities. (That is, libpng.so's ABI ought to change a lot less often than /usr/bin/emacs's: the former promises to provide a stable ABI and the latter never has.) 2) If a shared library's ABI does change, a Lisp update can fix the problem. On the other hand, if a strongly-coupled module becomes incompatible with the Emacs core, the remedy involves recompiling either Emacs or the module. It's much easier to update Lisp than to rebuild native code.