[EMAIL PROTECTED] wrote,
> Manuel M. T. Chakravarty writes:
> > "Erik Meijer" <[EMAIL PROTECTED]> wrote,
> [...]
> > 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.
For Corba you usually have to select an ORB first and you
need a language mapping - simply fewer variables with COM
(you pay with loss of portability).
> > 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.
I say GNOME because I mean a binding to all the important
GNOME services - not only ORBit, but also the GNOME
libraries.
> 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.
That's not what I meant. I was thinking about an
abstraction layer that can hide (some of) the differences
between COM and GNOME, so that a Haskell program can be
(source) portable across them (be warned, I didn't have a
serious lock into this, it is just an appealing idea).
> > 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?
You get a compile time error - either when running C->HS or
when running the output through the Haskell compiler.
> > 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 .
As far as I know there is none. Actually, the topic came up
on the GTK+ mailing list a while ago and there didn't seem
to be much enthusiasm for writing one. (There is a
interface specification file in a Lisp-like syntax, which is
used in the Guile and, I think, also Python binding of GTK+
- it didn't seem to be directly useful for Haskell when I
had a look at it at the beginning of writing the binding.)
Manuel
