Re: Easing language bindings (was Re: GtkPlot widget)

["Manuel M. T. Chakravarty" <chak is tsukuba ac jp>]

Havoc Pennington <hp@redhat.com> wrote,

> What I have in mind is generating the basic list of funcitons and types
> from the C headers; you assume that "the rules" are followed (bools are
> declared gboolean, returned gchar* are allocated, functions starting
> gtk_widget_ with a GtkWidget* first arg are supposed to be GtkWidget
> methods, etc.) 

How well are the rules followed in Gnome libraries (as
opposed to GTK+)?  They are, for example, not followed at
all in `gnome-http', which is one reason why I made a
binding for it (to check that my approach works with
libraries not playing by the rules).

This means, the libraries have to be changed (which may be a
lot of work) or the tool has to be more flexible (which
_may_ be more a matter of good design than pure coding
work).  All GTK+ headers have a fairly uniform structure,
because most of them are doing about the same thing
(defining a widget).  GLib and GDK are already less well
behaved and is probably be the need for even more diversity
in Gnome.

> and you have add-on information somewhere for all the
> exceptions, either in magic comments or in some kind of
> special file. 

I think, I would tend to having all extra information that
is not host language-specific in magic comments.  Otherwise,
you get - for one language binding - three files for each
header, which seems a but unwieldy.

> The bindings generator tool would slurp the headers + the
> exception info into a data structure, then each binding
> author would write code to walk this generic info and
> generate their bindings, possibly taking an additional
> language-specific exception list into account.

Please keep in bind that for some languages, the language
specific information is much more than an exception list.
As soon as the host language is statically typed and this
type system is different from C's type system, you will need 
a lot of additional information.

> Havoc
> (trying not to laugh at the idea of language binding authors deciding what
> language to implement this in... ;-)

To be honest, I for my part would be quite happy to continue 
using C->Haskell and extending it to grok any additional
information presented in the header files or in add-on
exception lists.  This is going to be much less work than
writing a Haskell backend for a new tool.

However, I am very interested in reaching a consensus on how
to represent extra information and how to treat it uniformly
in different language bindings.  I'd also be happy to invest
some work (read, code up some generic interfaces) in making
the generic parts of C->Haskell usable for languages other
than Haskell - but I can also understand if the other
language binding authors want to stick to their languages or 
to a less "exotic" common language.

Manuel