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] |
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 |