Generating Function Prototypes

Alastair Reid reid at reid-consulting-uk.ltd.uk
Sun Jul 7 17:45:49 EDT 2002


SimonM:
> I explained (in my previous message) that GHC needs
> header files and prototypes in order to generate correct foreign
> calls when compiling via C.  This is, IMO, a GHC-specific issue and
> doesn't have anything to do with the FFI specification - although
> confusion could be avoided if the spec pointed out that some
> implementations might need access to header files/prototypes in
> order to compile the code.

I think this is a very misleading way to describe the problem.  A
major goal of the ffi is to provide a portable way of interfacing
Haskell to C.  If we regard the header file as an optional extra which
some compilers need and some don't, then we have failed in that goal.
The effort of producing a header file is sufficient that ffi code
supplied without them will be very hard to port to ghc -fvia-C (and,
as I understand it, -fvia-C is considered the more stable platform
especially when doing ffi work).

One might argue that the whole area of ffi is rife with portability
problems because the portability problems encountered when writing,
compiling and linking C code leak into the ffi.  That is true to some
degree but:

1) We have tools like autoconf which help make the C side of things
   more tractable.

2) The task of transferring a few linker flags from one makefile to
   another is quite small compared with the task of writing a 
   suitable header file.

3) If I have m Haskell compilers and n platforms, then I have m*n
   combinations to worry about if the ffi is not portable but only n
   combinations to worry about if the ffi is portable between
   compilers.

-- 
Alastair Reid        reid at cs.utah.edu        http://www.cs.utah.edu/~reid/




More information about the FFI mailing list