> 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).
Sure, it's a problem, a bug in GHC, whatever. But I don't see a way
around it! We can't just generate prototypes because they might
conflict with prototypes already in scope. Trying to guarantee that
there are *no* prototypes in scope seems too fragile - I can't imagine
requiring that everything in ghc/includes must not #include any system
headers or declare prototypes for anything outside the RTS.
Note that in most cases you already *have* a header file because you're
writing a binding for an existing C library, so the act of producing a
header file isn't that much of a chore. Also you do get a small amount
of typechecking this way, whereas if we were somehow able to generate
prototypes then there would be no type checking at all.
Cheers,
Simon
_______________________________________________
FFI mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/ffi
