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: [EMAIL PROTECTED] | you have, half your time is spent
work tel: (0117) 954-5250 | waiting for compilations to finish.
_______________________________________________
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
