FFI proposal: allow some control over the scope of C header files

[John Meacham]

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.

I am not sure what my point is, perhaps just that it is not really a
haskell-prime language issue, but new pragmas are, so perhaps this is in
that regard.

in any case, in jhc a {-# INCLUDE foo.h #-} pragma has the effect of
adding "foo.h .." to every foreign ccall declaration in the current
module. Just a handy shortcut, not that I think that behavior should be
codified or anything.

        John

-- 
John Meacham - ⑆repetae.net⑆john⑈