The future of Haskell discussion

[Marcin 'Qrczak' Kowalczyk]

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