The future of Haskell discussion

[D. Tweed]

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.