On 02/13/2015 07:01 AM, Eli Zaretskii wrote: >> Date: Fri, 13 Feb 2015 04:17:17 -0800 >> From: Daniel Colascione >> CC: emacs-devel@gnu.org >> >> That's why this whole module effort is misguided and dangerous. With a >> CFFI-style approach to loading code dynamically, shared modules don't >> need to know anything about Emacs internal structure, so there are no >> ABI or source compatibility issues. >> >> I still think a CFFI port would be less work than trying to extract a >> stable Emacs internals API that modules can include. > > I don't understand how CFFI would solve the problem, at least not all > of it. We'd still need to write code to allow modules create Lisp > objects, right? That code would still be Emacs version dependent, > right? What am I missing? In a CFFI world, modules don't know about lisp at all. Lisp code describes the signatures of functions in loaded modules and calls into the automatically generated wrapper functions. The called code has no idea it's being called from lisp. If native code needs to create an object, it creates it in the normal way and returns a pointer; lisp then manages that pointer as an opaque value, possibly supplying it to further calls to that module's functions. This way, instead of loaded modules needing to track Emacs' historically unstable internal data structures, elisp needs to track module ABIs, which _have_ historically been stable; elisp interfaces can also be updated without requiring users have a compiler.