Re: lgtk-0.0.3 - experimental gtk bindings for Common Lisp

John Morrison <[email protected]> writes:
> For what it's worth...
> 
> For at least the past two years, I have used SWIG (www.swig.org) to
> generate bindings for C++ routines for a Lisp-like language, and
> wanted to extend that use for CMUCL bindings for arbitrary CV/C++
> code.  It took about 2K worth of C++ to generate a new SWIG
> "back-end."

Aha - Which Lisp-like language? Which bindings? I'd like to take a
look.

> However, even the SWIG guys have said that the hardest part is the
> parsing of the C++ code (doh!  what a non-surprise to
> S-expression-oriented people).  I got hit pretty hard by this.  SWIG
> would often keel over on perfectly legal C++ code, and it didn't
> really know what to do with templates.
> 
> However, within the past month or so I stumbled upon "gccxml" (use
> Google).  It looks like a much better way to go (although I have only
> gone so far as to download it and run it on very small test cases).
> Since it spits out XML (hey, it could be worse), I think it would be
> possible to do all the FFI stuff in Lisp.  I have only gone so far as
> to begin to explore which is the Common Lisp XML implementation of
> choice.  I would be interested in comments/advice from the clump
> community...

My thoughts on this are that there is some wisdom in choosing fights
you can win, and so I think that in most circumstances it is not very
wise to try to parse C/C++ headers, and then trying to understand
whatever you get. :-)

As an alternative, I like the probing approach from sb-grovel better:
produce c/c++ probes that print out the info you want, do what you
can't achieve this way either by hand or by ad-hoc glue generation.

I've heard from people trying to use gccxml that it disregarded so
much vital information (I don't remember the details) so that it was
essentially useless for this. But things might have changed, so don't
hesitate to find out and tell us ;-)

Another issue is that you want your bindings to make sense to language
users, and this means that you want to at least to take a look at it
and redo some interfacing decissions. An example might go like this:

int some_function (char *fname);
int another_function (char *str);

You want a different wrapper for the first one (that is able to cope
with cl pathnames) than for the second. You will need some fairly
advanced AI if you want this to happen automagically (and correctly!).

An alternative to that might be to have some infrastructure that
allows you to add functionality in a few easy steps. That is what I
have tried to achieve in lgtk, and for me it works nicely.

I have that vision of GUI with two text fields and a few buttons. I
paste some piece of a C header into one text field, and it produces
some lisp that it thinks is the correct binding. I may have to edit it
slightly, but after pressing another button, it is in the lib ready to
be used. Something like this should make it possible to write very
nice interfaces that feel native with a moderate amount of effort.

Regards,
        Mario.