FFI proposal: allow some control over the scope of C headerfiles

[Simon Marlow]

On 25 April 2006 09:51, John Meacham wrote:

> On Tue, Apr 25, 2006 at 09:40:58AM +0100, Simon Marlow wrote:
>> Admittedly I haven't tried this route (not including *any* external
>> headers at all when compiling .hc files).  It might be possible, but
>> you lose the safety net of compiler-checked calls.
> 
> yeah, perhaps a hybrid approach of some sort, when building the
> package, use the system headers, but then include generated
> prototypes inside the package-file and don't propagate #includes once
> the package is built. 
> 
> or just an intitial conformance check against the system headers
> somehow (?), but then only use your own generated ones when actually
> compiling haskell code. It would be nice to never need to include
> external headers in .hc files.

Hmm, the more I think about it, the more I like this idea.  It means we
could essentially forget about the public/private header file stuff, we
don't need the extra pragmas, and there would be no restrictions on
inlining of foreign calls.

Also, I've just checked and we #include very little when compiling .hc
files.  Just <inttypes.h> and <float.h> for HsFFI.h, and I suspect that
it isn't necessary to include HsFFI.h at all.

Cheers,
	Simon