From: | Paul Biggar <paul.biggar@gmail.com> |
Newsgroups: | comp.compilers |
Date: | Tue, 28 Jul 2009 12:09:01 +0100 |
Organization: | Compilers Central |
References: | 09-07-074 09-07-095 |
Keywords: | code |
Posted-Date: | 29 Jul 2009 08:39:19 EDT |
Hi Christoffer, Tony,
On Sun, Jul 26, 2009 at 6:55 PM, Tony Finch<dot@dotat.at> wrote:
> Christoffer Lerno <lerno@dragonascendant.com> wrote:
>>
>>I'd like to research FFI in various languages, basically to find the
>>best FFI-solution and copy from that one.
>
> Here's a link to a fairly useful survey/comparison of a number of
> embeddable/extensible dynamic/scripting language FFIs. It mostly covers
> Lua, Perl, Python, and Ruby, and Tcl also gets a few mentions.
>
> Hisham Muhammad and Roberto Ierusalimschy. C APIs in extension and
> extensible languages. In XI Brazilian Symposium on Programming Languages,
> Natal, May 2007.
>
> http://www.inf.puc-rio.br/%7Eroberto/docs/jucs-c-apis.pdf
In my opinion, the style of FFI used by scripting languages (Perl,
python, lua, PHP, Ruby) is awful, and should never be emulated. It is
particularly bad since most standard libraries are written using the
FFI (as opposed to being written in user-code), which cannot be reused
by other implementations of the scripting language.
Consider PHP. Its FFI is simply an API which exposed quite a lot of
the internals of the PHP interpreter. If you wish to provide another
implementation of PHP, you must copy or wrap the API (which is the
approach of Phalanger, a .Net version of PHP), ignore it (Roadsend)
and miss out on or reimplement all the libraries, or try horrendous
preprocessor and linker tricks to provide the same API (ProjectZero).
Every scripting language I've come across has the same style, as the
cited paper describes (although Ruby has at least put thought into
their API, and made it quite attractive). Some have come up with
better approaches, but they are not standard (Ruby's libFFI
[http://blog.headius.com/2008/10/ffi-for-ruby-now-available.html] or
Python's cython/pyrex [http://cython.org/])
In my opinion, the best approach is to provide a
domain-specific-language which allows libraries to call C functions
directly, along with a data type to wrap void-pointers. This is
similar to Cython/pyrex, which I consider the current best-of-breed
for scripting language FFIs.
Some more reading, if you're interested:
- The problems faced by PHP in this regard, see
http://wiki.php.net/rfc/remove_zend_api,
- ProjectZero describe a lot of the FFI problems they faced in
http://wiki.php.net/rfc/remove_zend_api/scratchpad,
- I give an overview of the "best approach" from above in
http://wiki.php.net/rfc/php_native_interface,
- Finally, I go into more detail about the problems with scripting
language FFIs in my SAC '09 paper:
https://www.cs.tcd.ie/~pbiggar/#sac-2009.
Thanks,
Paul
--
Paul Biggar
paul.biggar@gmail.com
Return to the
comp.compilers page.
Search the
comp.compilers archives again.