"Erik Meijer" <[EMAIL PROTECTED]> wrote,
> In H/Direct you define the interface of some software
> component in IDL (we have supported both MS-IDL and
> OMG-IDL from the beginning).
The H/Direct paper says (Section 2.2),
We focus on the IDL used to describe COM interfaces [10],
which is closely based on DCE IDL [7]. Another popular
IDL dialect is the one defined by OMG as part of the CORBA
specification [11], and we intend to provide support for
this using the translation from OMG to DCE IDL defined by
[13, 12].
So, did you support OMG IDL from the beginning or did you
only *intend* to support it from the beginning?
> The crucial point is that the
> component need not be written in C, it can be written in
> Cobol, Fortan, SML, ... (talking about being
> generic). Interfacing to just C is not enough.
True, but my point is interfacing to C does the job in a
sufficiently significant number of cases to justify
dedicated support - as you admitted when you advertised that
H/Direct will support reading .h files in the future.
> I gues that Manual is temporarily blinded by his free
> software fanatism (judging from his homepage
> <http://www.score.is.tsukuba.ac.jp/~chak/index.html>), and
Like you, I am an outspoken proponent of the software
development model that I believe is technically superior -
however, my enthusiasm does not make me call other people
"fanatic" on public mailing lists...
> as a result his paper contains quite some untrue
> statements with respect to the MS-centricity of H/Direct:
I can not remember having mentioned MS at all (apart when
quoting from your email).
> * page 1: "... to COM support [6,5]." (citing the H/Direct papers)
> OK, one more time H/DIRECT IS NOT TIED TO MS OR COM.
I did not claim this (and there is no reason to shout). Let
us look at the text that you are quoting in context:
Hence, it is not surprising that a number of methods have
been proposed for integrating foreign code into functional
programs, and in particular, for using imperative code
with Haskell [12]---approaches range from inline calls to
C routines [11] to COM support [6, 5].
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).
> * page 1: "Despite all this previous work, there is an
> interesting approach which has not been explored so
> far,......, access to existing libraries implemented in
> the language C.
>
> You could say that all FFI prior to H/Direct were about
> interfacing to C culminating in GreenCard.
Let's again look at the text that you omitted from your
quotation:
Despite of all this previous work, there is an interesting
approach, which has not been explored so far and which,
moreover, is especially attractive for the most frequent
application of a \emph{foreign language interface (FLI)}:
access to existing libraries implemented in the language
C.
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.
> * throughout the paper: you say that in your approach the
> programmer does not have to learn a dedicated interface
> language.
>
> Well, in some sense .h files are a dedicated interface
> language (and IDl is nothing more than a header file with
> some directional attributes).
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.
> Moreover, your binding hooks are nothing but a dedicated
> interface description language!
True, but a very simple one when compared to others.
> * page 9: "The design of a matching structure in Haskell
> requires algorithmic insight that hardly can be
> automated; neither can the structure be encoded in
> IDL. So, after all, the required marshalling has to be
> handcoded in Haskell."
>
> We have never claimed that this is the case. In fact, we
> have always said that the generated Haskell stubs are just
> the starting point of a long abstraction process to give a
> nice interface to a software component (see the papers
> "Haskell as an automation controller" and "Client-side
> scripting using HaskellScript").
And I have never claimed that you have claimed so -
actually, I would have been very surprised if you had.
> * last page: "... GHC's new FFI ..."
>
> 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?
> 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
>
> foo :: Int -> IO Int -- int foo ([in]int* x)
> foo :: Int -> IO (Int,Int) -- int foo ([in,out]int* x)
> foo :: IO (Int,Int) -- int foo ([out]int* x)
> foo :: Addr -> IO Int -- int foo ([in,ptr]int* x)
> foo :: [Int] -> IO Int -- int foo ([in,max_is(10)]int* x)
>
> or when the return value is some status code (as is the case in COM)
>
> foo :: Int -> IO () -- int foo ([in]int* x)
> foo :: Int -> IO (Int) -- int foo ([in,out]int* x)
> foo :: IO (Int) -- int foo ([out]int* x)
> .......
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.
Finally, let me quote from my last email:
> I for one never doubted that H/Direct is cool.
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.
For many tasks H/Direct is much better than C->HS, but that
does not prevent C->HS to be more convenient for some other
things. Anyway, I will make it very explicit in the next
version of the paper that H/Direct also allows to interface
to plain C (non-COM) libraries.
And, by the way, should you like to apologise for calling me
fanatic, I think, I'll happily accept the apology.
Cheers,
Manuel
