Hi fellow Haskellers,
First of al I want to apologize, especially to Manuel, for the immoderate amount of
emotion in my previous message. It was not professional at all; email is lightly
inflammable :-) As a scientist I find it rather frustrating that H/Direct is
associated so strongly with COM (which is very cool but timely) and not thought of as
a general foreign function interface (which is timeless).
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.
Of course I should have pointed this out gently and not blow up on Manuel. Next time I
see him, I will buy him a beer (or two).
> And, by the way, should you like to apologize for calling me
> fanatic, I think, I'll happily accept the apology.
I meant "fanatic" in the sense of passionate or enthousiastic (so consider it as a
compliment), not in the sense of extremistic or maniacal (in which case I am sincerely
sorry for saying that).
> Obviousy, references [6] and [5] are to support the claim
> that there is COM support for Haskell. Furthermore, [5] is
> the "Calling Hell from Heaven and Heaven from Hell" paper,
> which discusses nothing but H/Direct's COM support (plus
> GHC's new FFI).
In retrospect I think that the emphasis on COM was rather unfortunate from a marketing
point of view (as I tried to explain above). The reason for doing so anyway are that
(a) COM is a language independent *binary* interface and (b) there are many, very many
interesting COM components available. Both (a) and (b) are false for CORBA (but note
that Sigbjorn has made a CORBA binding as well) but true for Java via JNI (as Claus
already taught us ages ago, but I was temporarily blinded by my COM fanatism :-).
The reason that [5] discusses COM support (more precisely wrapping Haskell programs as
COM components) is because that is technically interesting. The basic "C" (more
precisely dynamic link library) binding is just part of that and was already described
in the first H/Direct paper.
It might be interesting to know that the Netscape Gekko browser is build out of
COM-compatible components, and that the JNI interface is also (nearly) COM compatible.
IMHO, the whole OLE framework is technically brilliant and deserves much more
appreciation from us hackers. In fact, I think that because most explanations of OLE
use C/C++, the inherent elegance gets burried under the accidental complexity of
pointers, arrays, HRESULTS, etc. and it could be done much nicer in Haskell.
> I admit that the wording is ambiguous, but the intended
> meaning is that "access to existing libraries implemented in
> the language C" is the most frequent application of a FLI -
> which is true.
I think that this really depends in which world you live. In Unix/Linux-land
components are usually distributed as C source files. In Windows-land you either get a
DLL or a COM component with a type library (a binary representation of its IDL
description), in which case you have no idea in which language the component is
implemented. Most probably Visual Basic! (but perhaps Haskell or SML, who knows).
I think that the latter is better; when I use a component I am usually (but not
always) only interested in it public interface. Only when something goes wrong or when
I want to modify the component, I start getting interested in its implementation. But
I would prefer to pay some money to the person from whom I bought the component
because it might be implemented in C++ or something in which I lack programming skils.
> The difference is that a programmer writing a Haskell
> binding to a C library already knows C and Haskell, but not
> necessarily IDL. Moreover, in my approach the already
> existing prestine C header file is used, which *always* is
> available for a C library. The IDL file you usually have to
> write yourself and constantly keep up to date with new
> releases of the C library.
But you "pollute" the Haskell-side with your hooks. I'd rather keep the Haskell side
pristine and edit the .h file by adding a few [in] and [out] attributes (i.e. you
don't have to write the IDL from scratch) or just use the IDL or type library or meta
data that comes with the modified library that is distributed in binary form.
> > Moreover, your binding hooks are nothing but a dedicated
> > interface description language!
>
> True, but a very simple one when compared to others.
In its full generality IDL is rather complex, but my experience is that for 80 percent
of all components you just need 20 percent of the power of IDL (maybe it is even
closer to 95/5).
> > This FFI is not specific to GHC, we proposed it as the
> > standard basic FFI for Haskell.
>
> I know, I used this phrase only due to lack of a different
> name for the FFI - any suggestions?
FFI is fine with me.
> > A more general question, which is not immediately clear is
> > how you specify the additional information to map a C
> > signature to Haskell. For instance
> >
> > int foo (int* x);
> >
> > can be mapped to many different Haskell signatures
>[...]
> This is done in Haskell, to avoid the burden of a more
> sophisticated interface language. The marshaling library
> that comes with the tool contains functions that do the job
> for frequently occuring cases. This is discussed in Section
> 2.2 of the paper.
I really think that IDL is not hard at all, and perhaps it is even simpler to
understand than your hooks. If you get an .h file with int foo(int* x) in it, you must
somehow know what the role of int* x is, i.e. is it an array, or an argument passed by
reference, etc. The IDL makes this crystal clear, e.g. int foo ([in,out]int* x). An
additional argument could be that you can just refer people to the many books that
discuss IDL so that you don't have to explain so much yourself.
> Nevertheless, it didn't help me when I wanted to code the
> GTK+ binding - partially because it was too beta and
> partially because it just automates the wrong things. So, I
> coded on the raw FFI (GHC's new one) by hand, and while
> doing this, I realised what kind of tool could help me and
> C->HS was born.
I am curious what it automates that you don't need, and what it does not automate that
you do need. We would love to get this kind of feedback so that we can make H/Direct a
better tool that makes you a happy camper and from which everybody can profit.
Yours,
Erik
PS Has everybody already registered for PLI http://pauillac.inria.fr/pli and the
Haskell workshop http://www.haskell.org/HaskellWorkshop.html ?
