The future of Haskell discussion
Marcin 'Qrczak' Kowalczyk
14 Sep 2001 19:06:13 GMT
Fri, 14 Sep 2001 18:04:24 +0300, Eray Ozkural <firstname.lastname@example.org> 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 * email@example.com http://qrczak.ids.net.pl/
^^ SYGNATURA ZASTĘPCZA