On Tuesday 17 June 2003 2:33 am, Abraham Egnor wrote:

I'd like to make a haskell binding for a C++ library. Most of the tools out there seem oriented towards c bindings, so it looks like I'll be writing the FFI code generator myself. While I'm at it I figure I might as well just make a general C++ binding tool. I've been thinking about this, and I'd like some feedback on the ideas I've had.

All previous interfaces to C++ libraries that I know of have been created by writing a bunch of wrapper functions with C-style types like these wrapper for a virtual function 'foo'. void foo_T(S x) { x->foo(); } void foo_T(T x) { x->foo(); } void foo_T(U x) { x->foo(); } [Note that these are C++ functions but that their type is one that C programs can call.] People have shied away from trying to create a more direct interface because: 1) C++ is a huge language (with the complexity mostly in types, classes and templates where you can't easily avoid them) and it seems that to be able to cope with any reasonable number of C++ libraries, you'd have to implement a large part of that language. 2) C++'s type/ class system is quite different from Haskell's class system. Any mapping of on to the other is likely to fall apart rather quickly. That said, I think H/Direct (http://haskell.org/hdirect/) is able to help a little with C++ and, even if it doesn't, it seems likely that an approach based on having Haskell and C++ interface to a third intermediate language (i.e., IDL) is most likely to work. -- Alastair Reid

Dear Abraham,

Now comes the question of how to map a C++ class hierarchy into haskell. It seems natural to try to map C++ classes into haskell typeclasses; however, there are a few issues involved with that.

You will quickly run into problems when doing that. The most important problem is that class instances are implicitly exported (ie. have a global scope). When different C++ classes implement the same methods, you will get unresolvable name clashes in Haskell. Fortunately, there exists a simple solution to model *single* inheritance object models in Haskell. It works with using phantom types where we encode the inheritance tree in the phantom type variable. Here is a quick example. Suppose we have the following classes: class Window { void Show(); }; class Frame : public Window { void SetTitle( const char* title ); }; class Control : public Window { ... }; class Button : publice Control { void SetLabel( const char* label ); }; Every object in Haskell will be represented by a simple "Ptr a". The phantom type "a" will encode the inheritance relation, that is, for each class we will create a new "phantom" data type that represents its class (or its part of the virtual method table). type Window a = Ptr (CWindow a) data CWindow a = CWindow Note that we will never use the "CWindow" constructor and that it therefore called a phantom data type. The "CWindow" type represents the Window class by itself, the "a" type variable represents the classes that may extend it. type Frame a = Window (CFrame a) data CFrame a = CFrame type Control a = Window (CControl a) data CControl a = CControl type Button a = Control (CButton a) data CButton a = CButton Ok, now that we have encoded the objects and inheritance relationships, we can give the signatures of all the methods: frameCreate :: IO (Frame ()) buttonCreate :: IO (Button ()) windowShow :: Window a -> IO () frameSetTitle :: String -> Frame a -> IO () buttonSetTitle :: String -> Button a -> IO () The creation function return objects where the type parameter is instantiated to unit () -- indeed such function creates exactly a Frame or Button, but nothing more. In contrast, a function like "windowShow" has its type parameter uninstantiated as it can receive any kind of window (any object that derives from a window). This corresponds to the contra-variance rule. do b <- buttonCreate windowShow b We can see that the above code does indeed work, the buttonCreate returns a "Button ()" that can be passed whenever a "Window a" is expected: Button () == Control (CButton ()) == Window (CControl (CButton ())) == Window a Pheew, quite a story. I hope it helps. You can read more about phantom types and inheritance in: Domain Specific Embedded Compilers, Daan Leijen and Erik Meijer. 2nd USENIX Conference on Domain-Specific Languages (DSL), Austin, USA, October 1999. Calling Hell from Heaven and Heaven from Hell Sigbjorn Finne, Daan Leijen, Erik Meijer, and Simon Peyton-Jones. Proceedings of the International Conference on Functional Programming (ICFP), Paris, France, 1999. and a recent paper with novel uses of phantom types to encode generic type constraints: James Cheney and Ralf Hinze. Phantom types. (I think it is published in "the fun of programming" ?)

I'd like to make a haskell binding for a C++ library. Most

I have done this for a upcoming wxHaskell library: a binding to the wxWindows GUI library. Just as Alastair, I also think that it is better to create (or generate) a C interface to the C++ library first, ie. extern "C" { void object_foo( Object* self, int arg ) { self->foo(arg); } } Furthermore, you probably need to generate dynamic link libraries (or shared object files) to link with GHC as the runtime systems of C (=GHC) and C++ are incompatible on many platforms.

First - it seems natural to use template haskell to do the code generation. That way, the library could either write the

I would advise against this: it is quite experimental and you would lock yourself into a single implementation. (I have made that mistake with haskellDB and TREX myself though :-). Since you will generate code anyway, you probably have no need for template stuff. All the best, Daan.

A separate datatype would have to be made for each C++ class to allow it to actually be instantiated, which isn't too bad. However, to allow haskell instances of the typeclass to call the old behavior it seems that there'd have to be duplicate functions of the ones in the typeclass, i.e.

class A a where foo :: a -> IO ()

foo_cpp :: (A a) => a -> IO ()

That seems to be needed to allow haskell instances to call the old implementation in their definition, but it rubs me the wrong way. Can anyone suggest an alternate method, or suggest a different direction entirely?

Abe

_______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell