Re: Wherein I argue for the inclusion of libnettle in Emacs 24.5

[Stefan Monnier <monnier@iro.umontreal.ca>]

> Emacs doesn't have a formal stable "internal ABI", anyway.

For purposes of providing encryption "subroutines", Emacs's API
has been pretty stable in this respect.  I might even claim that the ABI
has been pretty stable as well.

> 1) Carthage should be destroyed

We all agree so far.

> 4) FFI is nice for proprietary products, but sub-optimal for free software

Linking Emacs at compile-time with all the libraries someone might
potentially want to use at some point, leads for example to a Debian
package that depends on umpteen libraries.  It also forces people to
come and lobby here for each one of those libraries since it can only be
added to the core, thus slowing down the whole process.

The argument that "many systems don't ship with C compilers" is not
a good reason: that's just part of the problems that need to be solved
(and can be solved) when designing that FFI.  I.e. the question is not
"can we solve it" but "how are we going to solve it".

> If you allow binary modules to be inserted, they aren't that useful
> unless you lock down your internal ABIs.

As mentioned, a large part of that ABI has been very stable over
the years.  And we wouldn't need to freeze it for ever (e.g. require
a recompile when going from Emacs-23 to Emacs-24).

> And I think that would be a hindrance to further Emacs development.

The current situation is a hindrance to Emacs development.  An FFI is
not a panacea, of course, but it at least opens up new opportunities.


        Stefan