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]

Re: Foreign function interface generators.


Marius Vollmer writes:
> [I think we should discuss this on the list, if at all...]

I've included my original message at the end for the list readers.

> Ken Fox <kfox@ford.com> writes:
> 
> > If g-wrap had a *robust* C (and C++) parser in it, then it could
> > form the kernel [of] a wrapping toolkit.
> 
> The most intersting things about an interface are not visible from the
> C declarations, I'm afraid.  Like memory management, conventions about
> in/out parameters, real types of void pointers, interpretation of
> unions, etc.  We need something `better' than C for this.  Maybe CORBA.

I disagree.  CORBA might be useful for properly describing the semantics of
new libraries, but everything I've ever wanted to wrap is just a C or C++
library.  I would first have to translate the interface to CORBA and then
run a wrapper generator on it.  The Scheme interface would *still* suck
because CORBA doesn't support latent typing, keyword or rest arguments,
general closures, etc.  (Although I admit to not keeping up to date with
what the CORBA IDL supports.)

For example, when I wrap the X Toolkit library, I want to convert this C
interface:

extern Widget XtCreateWidget(
#if NeedFunctionPrototypes
    _Xconst _XtString   /* name */,
    WidgetClass         /* widget_class */,
    Widget              /* parent */,
    ArgList             /* args */,
    Cardinal            /* num_args */
#endif
);

into this Scheme interface:

(define (XtCreateWidget name widget_class parent . args) ...)

   name -- string or symbol
   widget_class -- symbol or widget_class object
   parent -- widget object
   args -- optional sequence of (name value) pairs
     name -- string or symbol
     value -- any type

I might also want to generate a class called "WidgetClass" with
a method called "CreateWidget".

This translation is simple once a few assumptions are made about the
library *and* the function definition for XtCreateWidget is properly
parsed.  Parsing the header files is the only really fragile/nasty part.
C is gross.

- Ken

Ken Fox writes:
| Subject: Re: Foreign function interface generators.
| To: mvo@zagadka.ping.de (Marius Vollmer)
| Date: Wed, 19 Nov 1997 17:52:32 -0500 (EST)
| 
| Marius Vollmer writes:
| > I don't think that it is such a bad thing to write a custom glue
| > generator for a particular library.  ...  The differences between
| > Scheme and C are too big to be automated away, I feel.
| 
| I agree, but the problem is more than just language mismatch, it's
| often the case that awkward (but regular) C interfaces can be
| translated to cleaner Scheme interfaces if certain assumptions are
| made about the code being wrapped.
| 
| I discovered this while wrapping the X/Xt/Motif libraries (in
| Perl, but the concept is the same).  The existing mechanical
| wrapping tools did a decent job, but the Perl interface was
| identical to the C interface.  Yuck!  I ended up writing a
| small-but-specialized wrapper tool that chose different wrapping
| approaches by looking at argument names, comments and other hints
| in the header files.  It took a few days to write, but most of
| that time was spent figuring out what assumptions were possible.
| 
| If g-wrap had a *robust* C (and C++) parser in it, then it could
| form the kernel a wrapping toolkit.  This would allow somebody to
| generate a highly customized interface, but not worry about silly
| details like whether the return type is on the previous line or
| whether argument lists are indented strangely.
| 
| - Ken

-- 
Ken Fox, kfox@ford.com, (313)59-44794
------------------------------------------------------------------------
Ford Motor Company, Powertrain           | "Is this some sort of trick
Analytical Powertrain Methods Department |  question or what?" -- Calvin
C3P Implementation Section               |