FFI again

[Stefan Monnier]

As you may remember, I'd really like for Emacs to grow some kind of FFI.
Last time we discussed it, I mostly remember the following points being made:
- An FFI can be a lot of work, and the benefit is not as obvious as it seems.
- Emacs-Guile would give us an FFI for free.
- The xwidget branch indirectly gives us some limited FFI.

The Emacs-Guile route seems promising, but I'm not sure I want to depend
on its schedule.  The xwidget one seems a bit too limited for my taste.
And I surely don't want to put a lot of work into it.

So I'd like an FFI, but one that's really cheap to design/implement.

The main purpose of an FFI, as far as I'm concerned, it to make it
possible for Emacs to use any .so library it feels, rather than only the
ones that it was compiled with.  More specifically, so that ELPA
packages can use such .so libraries if they feel like.

I think a "cheapish" way to do that is to make it possible for an ELPA
package to come with a .c file that exports a "syms_of_module" function
that can call things like defsubsr.

Installing such an ELPA package would require running a C compiler,
obviously (unless we also provide some pre-compiled versions for
particular target systems?).  And we'd need to add some function that
can load the resulting compiled object (along with the .so libraries it
depends on, since in many cases the whole purpose would be to call
functions in those .so libs).

It's not ideal, but it should be reasonably cheap to implement, and
would let people get access to pretty much any library they want.


        Stefan