Re: FFI again

[Stephen J. Turnbull]

Stefan Monnier writes:
 > > libxml, maybe.  libgnutls I would continue to provide a dedicated
 > > wrapper for.  It's very tricky to get the Lisp-to-C type matching
 > > robust in an FFI, and if there's a problem in the FFI you probably
 > > break all existing modules by fixing it.  In the meantime, if the FFI
 > 
 > IIUC this is the kind of problem I was referring to, which would be
 > mostly avoided by using an FFI system based on hand-written C wrappers:
 > you don't have to export to Lisp all the C-level details.

That's not FFI.  Are you confusing runtime loading of DSOs with a
foreign function interface (FFI)?  FFI means you can write bindings to
non-Lisp libraries in Lisp, rather than providing the ABI Lisp expects
using code in some other language.  The library called need not be
dynamically loaded, but in a dynamic language like Lisp, that's
obviously a very useful property.

XEmacs (and I believe SXEmacs) also has a *separate* facility for
dynamically loading C (and maybe C++?) modules (conventionally given
the extension .ell) with hand-written wrappers, written by J. Johnston
with loads of additional work by Jerry James and a few others.  This
integrates such modules with the feature system (`provide' and
`require').

Both facilities are useful but they are different, serving somewhat
different use cases.