On 02/13/2015 09:08 AM, Paul Eggert wrote:
> Eli Zaretskii wrote:
>> A well-designed set of APIs between Emacs and modules will avoid this
>> and other similar problems.  This has already been done at least
>> twice, in 2 different ways: in Make and in Gawk.
> 
> Sure, but the cffi/libffi approach has seen a lot more uptake than that:
> GCC, CPython, OpenJDK, PLT Scheme, etc., etc.  It's quite a well-trodden
> path.
> 
>> we have only one problem: design and implement a minimal set of
>> APIs necessary for modules to work, and keep it minimal.
> 
> cffi/libffi provides a good framework for that, no?  Why reinvent the
> wheel? Because that's what we'd need to do, when designing this new
> emacs.h file.

I was imagining emacs.h looking a lot like jni.h: modules would export
some kind of emacs_init symbol that the Emacs core would call --- say,
something like this:

struct emacs_runtime {
  /* Return NULL on failure */
  struct emacs_interface* (*init)(
    int interface_version,
    const char* my_license);
};

struct emacs_interface_1 {
  /* Err, something like this */
  struct emacs_value* (*defun)(const char* name, int nargs);
  struct emacs_value* (*funcall)(struct emacs_value* func, ...);
};

/* Exported by loadable modules and called on load.
   Return 0 on success or -1 on error. */
extern int emacs_init(struct emacs_runtime*);

This way, Emacs itself doesn't need to export any symbols and it can
support multiple interface versions sanely.

I'd still prefer a CFFI-style interface though.