RE: [Caml-list] Generating C stubs

["Jeff Henrikson" <jehenrik@yahoo.com>]

>>     and another one I don't recall (IIRC, someone claimed
>>     that he was working on a SWIG interface).
>
> That was me and I'm still working on it.  I just

No it was me!  ;-)  Actually I basically did write a SWIG
language module.  (How is it that we didn't see each others
work on the list archives?)  Anyway, after writing about
2000 lines of C code but before getting the bugs worked out,
I abandoned it.  My reasoning was:

1) SWIG is not sophisticated enough to get the behavior I
wanted easily.
2) Doing extra work to approach what I wanted was making
massive code bloat (SWIG is written in C and is not
forgiving of changing the "normal" behavior from the
language module end)
3) I hate programming in C, especially when the API has been
constructed to treat _everything_ as a void*.
4) Someone released a binding for the interfaces I needed

So that put the lid on that one for a while.  But I learned
why exactly I find it (and the IDL approach, and other FFI
systems) inadequate.  SWIG tries to be a little bit smarter
than IDL by letting you break away from the "this parameter
is [in], this parameter is [out]" level of abstraction, by
allowing some weak sorts of pattern matching.  In other
words, it can take the names of the parameters in a C header
file and say "make all int parameters named 'point' and
convert them this way.  But make all the int parameters
named 'color' and convert them this other way."   But it's
not general enough, and still makes the mistake of
annotating the header file rather than making the
annotations separate.  So when version 2.0 of your header
files come out, you start from scratch or do some silly
diff3 mucking around.

I started implementing a new header generator based on the
idea of describing the annotations as a caml program.
Basically have a bunch of convienience functions that search
through a C abstract syntax tree to ask things like this:

1) I need to use function FooOp which takes a datatype Foo*.
Read mydefs.h which contains their prototypes into the
current environment.

2) Find me all descendant types which are needed to build
the struct Foo.

3) Generate me constructor functions to build these ones
which I declare to be public members, and any of their
children.  For primitive types, convert using these C code
snippets I give you (ala SWIG typemaps).

4) Find me all functions which take a Foo* as a first
parameter.  Write C wrappers for them, caml external
declarations, and put them together as a class in an OOP
wrapper ala lablgtk.  Truncate the method names from
Foo_happyOperation to just myFoo#happyOperation by a regular
expression substitution, with exceptions which I specify by
hand.

Anyway, needless to say there's a bunch of stuff to be
worked out, but I may get back at the project soon, as I am
needing another API binding.  I really want to short circuit
the writing each function by hand as you go thing.  The
problem is that I usually work with APIs that I don't know
upfront, and want to just generate the stubs in bulk and
learn the API straight from an ML environment.  (This is one
of the areas where caml is definitely not as easy as C yet.)
I think 95% of the necessary information is already
contained in well stylized header files, we just need a way
of systematically cleaning up the last 5% into a complete
IDL level of knowledge.

Two further extensions of such a system would be to

1) produce a language independent output, in other words
write out IDL instead of C wrappers.

2) construct a language independent input, so that non-caml
programmers might be seduced.  :->

Regards,


Jeff Henrikson


-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners