On Wed, 2008-03-05 at 23:46 +0000, Ross Paterson wrote:
On Wed, Mar 05, 2008 at 11:16:14PM +0000, Duncan Coutts wrote:
I was under the impression that with ghc, ffi import declarations like this do not escape the module:
foreign import ccall unsafe "foo.h foo" foo :: IO ()
GHC can inline the stub across module (and thus package) boundaries, so the #include can escape.
I've been informed before that: foreign import ccall unsafe "foo" foo :: IO () can escape and needs -#include on the command line and for all client code. However for ghc: foreign import ccall unsafe "foo.h foo" foo :: IO () does not escape because ghc does not track which .h file should be #included later. It's not that it couldn't escape according to the FFI spec but that ghc currently does not do cross-module inlining for such declarations. That's what I've been told and it's the behaviour I've observed, except for the case I noted. Quite a few packages rely on ghc's behaviour on this, or just rely on the fact that in practise things do not get inlined that aggressively. If we started looking carefully I think we'd find most hackage packages that use FFI get this wrong.
It's hard to tell what header files need to be used globally and inherited by client packages and which can safely be used privately.
No, it's easy: they're all potentially inherited.
Which is really annoying :-) I'd like greater control over it, in particular a way to limit headers to package scope so that dependent code does not need the headers. Duncan