You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
Chapter 4: An Introduction to Foreign Interfaces and <strong>CFFI</strong> 4<br />
4 An Introduction to Foreign Interfaces and <strong>CFFI</strong><br />
<strong>User</strong>s of many popular languages bearing semantic similarity to <strong>Lisp</strong>, such as Perl and<br />
Python, are accustomed to having access to popular C libraries, such as GTK, by way of<br />
“bindings”. In <strong>Lisp</strong>, we do something similar, but take a fundamentally different approach.<br />
This tutorial first explains this difference, then explains how you can use <strong>CFFI</strong>, a powerful<br />
system for calling out to C and C++ and access C data from many <strong>Common</strong> <strong>Lisp</strong><br />
implementations.<br />
The concept can be generalized to other languages; at the time of writing, only <strong>CFFI</strong>’s C<br />
support is fairly complete. Therefore, we will interchangeably refer to foreign functions and<br />
foreign data, and “C functions” and “C data”. At no time will the word “foreign” carry its<br />
usual, non-programming meaning.<br />
This tutorial expects you to have a working understanding of both <strong>Common</strong> <strong>Lisp</strong> and<br />
C, including the <strong>Common</strong> <strong>Lisp</strong> macro system.<br />
4.1 What makes <strong>Lisp</strong> different<br />
The following sums up how bindings to foreign libraries are usually implemented in other<br />
languages, then in <strong>Common</strong> <strong>Lisp</strong>:<br />
Perl, Python, Java, other one-implementation languages<br />
Bindings are implemented as shared objects written in C. In some cases, the<br />
C code is generated by a tool, such as SWIG, but the result is the same: a<br />
new C library that manually translates between the language implementation’s<br />
objects, such as PyObject in Python, and whatever C object is called for, often<br />
using C functions provided by the implementation. It also translates between<br />
the calling conventions of the language and C.<br />
<strong>Common</strong> <strong>Lisp</strong><br />
Bindings are written in <strong>Lisp</strong>. They can be created at-will by <strong>Lisp</strong> programs.<br />
<strong>Lisp</strong> programmers can write new bindings and add them to the image, using<br />
a listener such as SLIME, as easily as with regular <strong>Lisp</strong> definitions. The only<br />
foreign library to load is the one being wrapped—the one with the pure C<br />
interface; no C or other non-<strong>Lisp</strong> compilation is required.<br />
We believe the advantages of the <strong>Common</strong> <strong>Lisp</strong> approach far outweigh any disadvantages.<br />
Incremental development with a listener can be as productive for C binding development<br />
as it is with other <strong>Lisp</strong> development. Keeping it “in the [<strong>Lisp</strong>] family”, as it were, makes<br />
it much easier for you and other <strong>Lisp</strong> programmers to load and use the bindings. <strong>Common</strong><br />
<strong>Lisp</strong> implementations such as CMUCL, freed from having to provide a C interface to their<br />
own objects, are thus freed to be implemented in another language (as CMUCL is) while<br />
still allowing programmers to call foreign functions.<br />
Perhaps the greatest advantage is that using an FFI doesn’t obligate you to become<br />
a professional binding developer. Writers of bindings for other languages usually end up<br />
maintaining or failing to maintain complete bindings to the foreign library. Using an FFI,<br />
however, means if you only need one or two functions, you can write bindings for only those<br />
functions, and be assured that you can just as easily add to the bindings if need be.