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

[Simon Marlow]

On 24 April 2006 23:21, John Meacham wrote:

> It is my understanding that the FFI foreign imports declare an ABI and
> not an API, meaning the exact way to make the foreign call should be
> completely deterministic based on just what is in the haskell file
> proper. Otherwise, obviously, direct to assembly implementations would
> be impossible.
> 
> In this sense, include files are always potentially optional, however,
> due to the oddness of the C langauge, one cannot express certain calls
> without proper prototypes, current haskell implementations take the
> straightforward path of relying on the prototypes that are contained
> in the system headers, which also incidentally provides some safety
> net against improperly specified FFI calls. However, it would also be
> reasonable for an implementation to just generate its own prototypes,
> or use inline assembly or any other mechanism to implement the FFI ABI
> calls properly.

This comes up quite often.  The reason that GHC doesn't generate its own
prototypes is that we would have to be *sure* that there aren't any
other prototypes in scope for the same function, because those
prototypes might clash.  We can't generate a correct prototype that is
guaranteed not to clash, because the foreign import declaration doesn't
contain enough information (no const annotations).

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.

Cheers,
	Simon