Food for thought: Numeric.Special

[Alastair Reid]

Keith.Wansbrough writes:
> Automate!
>
> You must avoid actually writing the import declarations for each
> function by hand.  

If the functions are all of the complexity of sin, cos, etc., it is hard to 
improve significantly on:

  foreign import ccall sin :: Double -> Double

There's just not much information you can leave out of this.
(Perhaps you could save the first three tokens but they're not that hard to 
cut and paste).

You'll see some benefit from ffi preprocessors on functions with complex but 
regular marshalling requirements like passing arrays or tuples and returning 
Maybes, error codes and multiple return values.  The GreenCard preprocessor 
is especially good here.

Where you'll see most benefit from an ffi preprocessor is when you have to 
interact with non-primitive C datatypes (structs, unions, enums, typedefs).  
hsc2hs and c2hs are probably the strongest at this sort of thing.

> With any luck, you can write a script to
> automatically turn the .h file into a .hs file, and save yourself all
> the work.

Manuel's c2hs tool can do some of this (and I think it's the only tool that 
does).

IIRC, it parses header files to extract type information so that if you write:

  sin = {#call pure sin#}

it can fill in the type information for you.  [Manuel: please correct any 
errors in the above.]

It is still up to you to decide which functions you want to interface to and 
for complex cases, you still have to say how to marshall the code.

Note that with any tool which extracts information from header files, you will 
have to think about how to make your distribution portable.  With hsc2hs, 
this means shipping the .hsc files it generates.  With c2hs, it means that 
people need to install c2hs on their machine.

--
Alastair Reid