scope of header files

[Duncan Coutts]

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