FFI: control over the scope of C implementations?

kahl at cas.mcmaster.ca kahl at cas.mcmaster.ca
Mon Apr 24 10:08:25 EDT 2006

Simon Marlow <simonmar at microsoft.com> just wrote:

 > How about just adding a couple of new pragmas:
 >  {-# INCLUDE_PRIVATE "foo/bar.h" #-}
 >  {-# INCLUDE_PACKAGE "foo/bar.h" #-}
 > both pragmas apply to all the foreign imports in the current module,
 > just like the existing INCLUDE pragma.  Additionally, INCLUDE_PRIVATE
 > prevents any foreign import from being inlined outside the current
 > module, and INCLUDE_PACKAGE does the same but for the package (this
 > requires a little more support from GHC).

Probably I am now opening a can of worms:

A Haskell ``import M (f)'' instructs the implementation to look for BOTH
 - the declaration (typing) of ``f'', AND
 - the implementation of ``f''
inside module ``M'', wherever that can be found with current path settings.

In contrast, a ``foreign import ccall "foo/bar.h f"''
only provides analogous help for locating DECLARATIONS.

While we limit declaration tracking,
shouldn't we do the same for implementation tracking?

Perhaps (just a quick first attempt to get the idea across):

{-# INCLUDE_PRIVATE "foo/bar.h" "foobar.o" #-}
{-# INCLUDE_PACKAGE "foo/bar.h" "-lfoobar" #-}

I would have considered allowing just

{-# INCLUDE_PRIVATE "foo/bar.h" "foobar" #-}

and turning this into ``-lfoobar'' on the linker command line,
but probably the ``foobar.o'' option is useful in some contexts.

By the way, I do not think that an implementation
necessarily has to avoid inlining of limited imports;
I think it also could choose to keep the necessary information around
in the hidden parts of the package.
Users of the package just cannot add foreign imports using those .h files,
in the same way as they cannot import hidden Haskell modules.

Inlining Haskell functions from hidden modules is not forbidden either
(I hope...).



More information about the Haskell-prime mailing list