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