How many times do I have to repeat that H/DIRECT IS NOT TIED TO MS OR COM, once again
H/DIRECT IS NOT TIED TO MS OR COM!
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 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.
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 as a result
his paper contains quite some untrue statements with respect to the MS-centricity of
H/Direct:
* 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.
* 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.
page 1: "Interfaces to operating system services as well as to system-level and
higher-level libraries are usually available from C, ...".
If "usually" means Unix/Linux then you are right.
* page 3: "This is all very well for the main application area of H/Direct --namely
writing COM components in Haskell-- but seems a bit heavy when merely interfacing to
an existing C library.
The main application area of H/Direct is to provide a language independent FFI;
H/DIRECT IS NOT TIED TO MS OR COM.
* 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). Moreover, your binding
hooks are nothing but a dedicated interface description language!
* 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").
* last page: "... GHC's new FFI ..."
This FFI is not specific to GHC, we proposed it as the standard basic FFI for Haskell.
At this moment it has only been implemented for GHC, but work is underway to support
ing under Hugs as well.
I agree completely :-) that it is *very* important to have a standard FFI that is
supported by all Haskell implementations.
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)
.......
Yours,
Erik
