Re: Dynamic loading progress

[Daniel Colascione]

On 02/13/2015 07:01 AM, Eli Zaretskii wrote:
>> Date: Fri, 13 Feb 2015 04:17:17 -0800
>> From: Daniel Colascione <address@hidden>
>> CC: address@hidden
>>
>> 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.

signature.asc
Description: OpenPGP digital signature