[mercury-users] Working with exported types

[Jonathan Morgan]

On 7/27/06, Peter Moulder <Peter.Moulder at infotech.monash.edu.au> wrote:
> On Thu, Jul 27, 2006 at 04:51:09PM +1000, Peter Wang wrote:
>
> > Does it?  I'm interested in importing C constants *into* Mercury,
> > without going through the contortions you've gone through in the OpenGL
> > binding.  At the moment the easiest way to do that is to hard-code the
> > value into the Mercury code, but that's brittle.

It is indeed a problem - at both sides of the equation you wish to use
a symbolic name that the other side will not recognise.  However, it
would probably break a large collection of existing code that relies
on a particular ordering of enums, rather than just any ordering that
happens to reflect the underlying code - including some that have
multiple aliases defined to the same value.

> If interfacing with an existing C/C++ library that has an enum, then one
> option to consider is to add a Mercury target to SWIG (http://www.swig.org/).
> Swig already supports 13 target languages (including ocaml, excluding
> haskell, goedel or any other purish language that I can recognize --
> there are a couple of languages I haven't heard of).

Many libraries use #define's rather than enums - which SWIG cannot
really know about very well.

> This approach may take care of more of the problem of interfacing to
> existing foreign code -- of which enum maintenance is a tiny part.
>
> Someone once said "interfacing to foreign code from Mercury is easy, you
> just add a wrapper function for each foreign function you need to call";
> but "each function you need to call" can be a large number, and Mercury
> has very few bindings to other languages.

Functions are generally fairly straightforward - but callbacks are
generally much more messy.  Mercury foreign language code can easily
become unmaintainable.

> I realize that making a natural binding for an imperative language can't
> be completely automated, but even automating just part of it would still
> be helpful when wrapping a large existing library, and in some cases one
> is content with an un-idiomatic binding (passing !IO everywhere).

Including libraries that do a lot of IO anyway.  I have considered a
SWIG binding or something similar.  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).

However, most of my questions have come from working with Gtk+, which
provides an object-oriented library written in C.  This
object-orientation will not be recognised by SWIG, so it doesn't fill
my needs.  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, and if there is a binding
generator it will be very specific to GObject based APIs.

I do think that the automation of binding generation could be very
useful, but in places it will need a lot of hand-tuning.

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