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 _______________________________________________ Glasgow-haskell-users mailing list [email protected] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
