[mercury-users] Foreign Language Interfacing [was: Working with exported types]

[Jonathan Morgan]

On 7/28/06, Peter Moulder <Peter.Moulder at infotech.monash.edu.au> wrote:
> On Thu, Jul 27, 2006 at 10:15:46PM +1000, Jonathan Morgan wrote:
>
> > Many libraries use #define's rather than enums - which SWIG cannot
> > really know about very well.
>
> http://www.swig.org/compare.html claims that swig does handle #defines;
> though presumably each #define would be mapped to an independent
> function returning a generic type like int.  I don't think this is too
> much of a problem: the developer's reasons for #defining to an int (e.g.
> use in arithmetic) may well apply to Mercury code too.

It may - it may just mean that the developer knew about #define's, but
not enums, or that the developer preferred #define's (when working
with some compilers in the past I have used #define's exclusively, as
it facilitated reading from and writing to files, because there were
no guarantees about assigning ints to enums and vice versa.).

> > However, while SWIG is fairly good for C, it needs a lot of guidance
> > when binding quite a few C++ constructs (this may or may not be a
> > problem).
>
> The same page claims that "SWIG provides wrapping support for almost all
> of ANSI C++", followed by a table of things supported, and a couple of
> paragraphs on things not supported, of which it describes nested classes
> as the most important thing not yet supported.
>
> The only thing it lists as needing guidance is that templates must be
> explicitly instantiated.  There is a larger list of "Customization
> features" that Jonathan may be counting as "needing guidance".

It is not a complaint against SWIG.  C++ is a far more complex and
flexible language than most (all?) of SWIG's target languages.  C++
that is "idiomatic" in some sense will often use the STL in various
ways, as well as overloaded functions/methods, which don't work very
well in many languages.

> > I'm currently experimenting with using XML files used to generate
> > Gtk#, the C# binding to Gtk, but they don't always have all the
> > information that Mercury needs
>
> It would be nice to extend the XML DTD: information needed by Mercury
> may well be useful to similar languages.

A technical point: the XML doesn't actually have a DTD - it is
generated by a perl program parsing the Gtk header files.  However, in
some cases the information is actually there, but not readily usable.
In this case other tools might be able to extract it.  If I need to
modify the parser I will, but I would prefer to continue to rely on
the XML files I can get from Gtk# as long as possible.

Another option is to use the XML files generated by SWIG.  I do not
think that this option is a good one, as the XML files generated by
SWIG are extremely complex.

> I've just looked up how people do a gtk binding for Haskell: the Gtk2Hs
> developers use the `C->Haskell' interface generator
> (http://www.cse.unsw.edu.au/~chak/haskell/c2hs/),
> and copy/adjust C gtk's documentation by hand.

I surveyed various options for automatic generation.  I do not think
that a tool like c2hs would work very well for Mercury.  My impression
is that it relies more on a mixture of marshalling done both on the C
side and on the Haskell side, and on direct imports to Haskell of C
functions.  However, it is more common in Mercury for most marshalling
to be done in foreign code.  pragma import has never really been used
and is likely to be phased out in the move to the new foreign language
interface.

I prefer to work on a custom binding generator because the XML files
generated by Gtk# have already read some meaning into the headers, and
are thus at a higher level of intent than a simple C binding
generator.  Also, I have full source code for the Gtk# generator,
which is a useful source for ideas and understanding, and I know that
the files I am using have been successfully used for binding before.
The work may be useful later for other things, but that is not my
primary intention.

Jon
--------------------------------------------------------------------------
mercury-users mailing list
Post messages to:       mercury-users at csse.unimelb.edu.au
Administrative Queries: owner-mercury-users at csse.unimelb.edu.au
Subscriptions:          mercury-users-request at csse.unimelb.edu.au
--------------------------------------------------------------------------