Manuel M. T. Chakravarty writes:
> "Erik Meijer" <[EMAIL PROTECTED]> wrote,
[...]
> > There is a real danger if in an officially published paper
> > someone gives the impression that H/Direct is only about
> > interfacing Haskell to COM, because readers that will hear
> > about H/Direct for the first time via that paper could
> > become. When discussing related work you have to be 300%
> > extra careful because you are potentially influencing the
> > mindset of your readers.
>
> IMHO, the H/Direct papers nurture this impression. To be
> honest, although I realised that H/Direct can generate plain
> C bindings, I always thought that the only thing you (= the
> authors of the papers) really care about is the COM
> support. From the discussions about H/Direct on the mailing
> lists, I believe that I am not the only person who
> interpreted the papers in this way.
I made the same interpretation. I had the strong impression that OMG IDL support
did not exist at present. If I now understand correctly, OMG IDL is currently
accepted by H/Direct (has anyone tested this ?) and what is lacking is a Haskell
language binding for CORBA.
> I understand that the fact that COM fixes the binary
> interface makes it much easier to deal with.
I don't understand this - perhaps you could explain.
> As I wrote
> in response to Daan, I am seriously thinking about getting
> H/Direct to work with GNOME. Maybe this way we can arrive
> at something that is more or less portable at least on the
> Haskell level.
Presumably you mean ORBit, rather than GNOME. According to its documentation,
ORBit supports IIOP, therefore Haskell would interface to any other language via
ORBit. For example, to have Haskell call COBOL (ugh!), one would simply let
ORBit talk IIOP to DAIS (an ORB with a COBOL binding) or vice-versa.
> My point is that in most cases, I don't have control over
> the .h files. I get them with the library. If I edit them,
> I have to do this for every new version. This would be
> quite tedious for something like the GTK+ binding.
>
> In contrast, the Haskell-side is completely under my control
> and I am actually quite happy to get an error message that
> forces me to look at the code when something on the C side
> changes.
Will you always get an error message if the C signature changes without a
corresponding change in the Haskell signature, or is it possible you will just
get a segmentation fault ? In this case, it might be preferable to have IDL as
the official interface, with the C and (preferably) Haskell interfaces generated
from the IDL (except that IDL is not sufficiently rich for interfacing to a
language like Haskell).
> The first and foremost thing is that writing an IDL for GTK+
> is a lot of work - we are talking more than 400 kbytes .h
> files here. There are of course some functions that need a
> lot of special treatment in the interface, but many of the
> functions have rather uniform marshaling requirements. So,
> what I wanted was not touching the .h files (or respecifying
> them in IDL), but only tweaking on the Haskell-side where
> this is necessary. That's exactly the reason why I came up
> with the design that I descibe in that paper.
One would expect GTK to have a CORBA (i.e. IDL) interface for its use in the
GNOME project, but I couldn't see any sign on www.gtk.org .
Tim
