As a general question (and forgive my ignorance): are the various ffi's implemented using something like `dlopen' or are they done by actually putting suitable stubs into the Haskell generated C-code which then gets compiled by the C compiler as part of the overall haskell compilation? On 14 Sep 2001, Marcin 'Qrczak' Kowalczyk wrote:

I think it should be easy to add support for C++, except exceptions.

There are two approaches: call C++ functions directly (it requires implementing name mangling by the Haskell compiler; there are several name mangling schemes and gcc changed its scheme in version 3.0) or write C wrappers (this is inconvenient but is doable now without compiler support).

I suspect that there's several different levels of C++ interface; here's mty personal taxonomy (which other people may disagree with :-) ) : (1) Firstly there's calling code where the interface is basically C but compiled with C++; at this level there's the issue of name mangling (accounting for both for argument structure and namespace effects) and any global stuff in the C++ code (e.g., ensuring global objects construction/destruction happens at times that are ok). (2) Then there's being able to invoke the method of an object without caring about moving `inside object' information back in to haskell (e.g., calling the colour_segment() member of an object of the Image class). Here the object is essentially just acting as a `struct with attatched function pointers'. (3) Then there's being able to actually use objects more fully via a Haskell type/type-class wrapper of some sort (so that for example objects of C++-class X_cpp with a member function string show(void) const could be used in, e.g, display :: [X_haskell] -> IO() display = sequence (map (putStr.show)) Obviously this throws up issues of the semantics that need to be solved (e.g., can I only use const member functions, or can I use them all providing I embed the object in a monad?) and is (I imagine) a heavy research and implementation project. (4) Finally there's being able to propagate C++ exceptions into Haskell, using either Haskell exceptions or some other representation. (This is clearly incredibly hard, but I belive some package (forget which) manages to propagate C++ exceptions into Python exceptions.)

From my limited understanding, the really nice bits about the KDE framework (e.g., embedding application objects inside others) would require at least level (3) and possibly even (4).

An annoyance is that templates can't be called directly but each instance must be imported separately.

Indeed, with a potential additional problem: many template functions are written as inlines in header files, so that if I try and use a template function I wrote years ago in a .cc file containing a C++ class I defined yesterday I silently get the correct code compiled into the new .o file. If I try to `glue' together a template function and a new C++ type (where they haven't been used together otherwise) where does the new instantiation go; do I have to go around adding explicit instatantiation requests in the C++ source?

On Linux it works when main() of a mixed C/C++ program is written in C. AFAIK it doesn't work everywhere. Nevertheless an example I've now made worked.

hsc2hs and ghc need to be extended to make it work smoothly. hsc2hs produces a file with extension .c and ghc compiles these files by passing -x c options to the C compiler, so even if a C++ compiler is substituted, it is compiled as C. There should be a switch in hsc2hs to let it produce C++ and ghc should recognize .cc extension, or in some other way ghc should be informed that the .c file is really C++. Option -pgmlg++ causes ghc to link using g++; option -lstdc++ instead also works. And hsc2hs should be taught about extern "C".

All these are useful things; however I'm just pointing out that there's various degrees of interoperation with C++. My personal position at the moment is that I want to be able to use the level 1 facilities above with minimal effort (and to be able to call in to Haskell from C++, but that's another story) for program development purposes. If there's any coding that better informed people can suggest to make interfacing with C++ easier I can try and help with it, but unfortunately (1) I'm unreliable; (2) I can't justify doing development on interfacing C++-Haskell as part of my job so it'd only be during my very scarce free time; (3) did I mention I'm incredibly unreliable? ___cheers,_dave________________________________________________________ www.cs.bris.ac.uk/~tweed/pi.htm |tweed's law: however many computers email: tweed@cs.bris.ac.uk | you have, half your time is spent work tel: (0117) 954-5250 | waiting for compilations to finish.

"Marcin 'Qrczak' Kowalczyk" <qrczak@knm.org.pl> writes:

Fri, 14 Sep 2001 02:09:21 -0700, Julian Seward (Intl Vendor) <v-julsew@microsoft.com> pisze:

...

The lack of any way to interface to C++ is a problem, IMO. I would love to be able to write Haskell programs using Qt and ultimately the KDE libraries, both of which are C++, but I can't, at the mo.

I think it should be easy to add support for C++, except exceptions.

for info, Qt/KDE do not use exceptions and compile with -fno-exceptions