Fri, 14 Sep 2001 18:04:24 +0300, Eray Ozkural <erayo@cs.bilkent.edu.tr> pisze:

I understand that you ought to deal with name mangling at some stage, but how would the interfaces ultimately look like?

It depends how sophisticated tools we create. The easy step is to wrap everything in functions. They would be C functions for the moment. For example a plain method would be wrapped in a C function with 'this' as one of arguments. With C++ support in the Haskell compiler it can be more convenient for overloaded functions and even non-virtual methods. Unfortunately for calling a virtual method or getting a field out of a struct/class it's not enough to supply what the programmer sees (function name and types involved) to generate the code; the object layout matters. Currently ghc doesn't deal with C/C++ object layout at all, and I imagine it would be very hard for it to do this (how to interpret a C++ header?). OTOH tools like hsc2hs and c->hs can support this; they already can handle C struct fields. I think calling a virtual method requires creating a function wrapper, but tools should cope with this in future.

If you can do non-template C++, then it wouldn't be difficult to call template code. Just do an explicit instantiation of the template code in an auto-generated .cxx file. What's the problem there?

Usually it should not be a problem, because arbitrary Haskell objects can be represented only as something like StablePtr in C++, so templates working on Haskell objects don't need many instantiations. But a sophisticated cooperation between Haskell and C++ should probably create custom C++ classes for wrapping different kinds of Haskell objects, and then clients of a Haskell interface to a C++ library must instantiate templates themselves. -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK