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 > [EMAIL PROTECTED] > http://www.haskell.org/mailman/listinfo/haskell > > _______________________________________________ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell