This is the mail archive of the guile@cygnus.com mailing list for the guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Foreign function interface generators.




I'm trying to use guile to do some work and need a decent foreign
function interface generator.  The choices from the ftp site seem to
be SWIG, g-wrap and ffi.  None seem to fit my needs completely, so, I
thought I would try to start a discussion about ffi generators in
general to get some progress toward a workable system for guile.

SWIG, while quite powerful, seems to be more than I want.  In
particular, I found it to have a pretty large cognitive startup time.
Also, it seems appropriate for someone developing a library that wants
to target many interface languages.  I feel I want something that
makes it easy to import libraries that others have done, with the
minimum of complexity.

I've used g-wrap before and like it for it's simplicity, but it needs
some beefing up.  I find the features of ffi attractive as well,
though they aren't what I need at the moment.

So, I've decided to stick with g-wrap for the moment, modifying it
myself if necessary.  I'd prefer that the entire community benefitted,
thought, and to that end I offer a few minor comments.  I expect I
will have more soon.



****************************************************************

The following comments refer to the documentation at:

   http://www.cs.cmu.edu/afs/cs/usr/chrislee/www/g-wrap/g-wrap.html


The formats of `new-function', `new-type', and `define-constant' seem
somewhat inconsistent. I believe they could be slightly modified in
form to make them more consistent with each other, more Scheme-like,
and easier to remember.

First, I don't think these functions should be passed Scheme
symbols. Rather, they should return Scheme objects which are
associated with a symbol using the standard ``define'' and ``set!''
forms.  For example, the following:

   (define-constant "VNULL" "NULL" VEC)

would become:

   (define VNULL (gwrap-c-constant "NULL" VEC ))

Similarly:

    (new-function c-name scheme-name ret-type type-list description)

would become:

    (define scheme-name (gwrap-c-function
                           c-name ret-type type-list description))

Note that the ``new-type'' function has this form already:

    (define scheme-name (new-type c-name c-print-name
                         c-die-name c-eq-name c-gc-name))

but the function name should be changed to something consistent with
the others, e.g.:

    (define scheme-name (gwrap-c-type c-name c-print-name
                         c-die-name c-eq-name c-gc-name))


This new naming scheme is more consistent with the naming of the
auxiliary functions for dealing with C files, e.g.,
c-file-include-local-header. I believe these should be slightly
reworked as well.

Specifically, the naming conventions should reflect that the function
is part of g-wrap.  Also, all function names should make it clear what
language is being ``wrapped,'' i.e., imported into Scheme.  Hence the
prefix ``g-wrap-c'' on all the functions.

Perhaps g-wrap should be a module, but I guess that you would make it
less portable.

-- 
Clifford Beshers          Computer Graphics and User Interfaces Lab
beshers@cs.columbia.edu              Department of Computer Science
http://www.cs.columbia.edu/~beshers             Columbia University