"Erik Meijer" <[EMAIL PROTECTED]> wrote,
> First of al I want to apologize, especially to Manuel, for
> the immoderate amount of emotion in my previous
> message.
Already forgotten.
> 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).
I can understand this and it was definitely not my intention
to add to your frustration.
> 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.
Anyway, I promise to make it superclear in the next version
of my paper that H/Direct is *not* only about interfacing
COM.
> 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.
That's interesting, I didn't know that.
> 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 believe this and I actually very much like the H/Direct
papers, especially Heaven and Hell. It is only rather
unfortunate that this technology is tied to a single
platform - I don't care who the vendor of this single
platform is, but being tied to a single platform is a Bad
Thing. One reason for me to choose GTK+ as the GUI for
which to write a binding was that it runs on basically all
Unix machines *plus* Win32 and a Mac port is in the works.
I understand that the fact that COM fixes the binary
interface makes it much easier to deal with. 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.
> > 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).
Sure, but I believe that also on Win, most libraries
(especially the system-level and basic libraries) are *also*
available from C (I mean any of the C development systems) -
or am I mistaken? This would be sufficient.
> > 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.
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.
> > 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.
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.
Cheers,
Manuel
