control over the scope of C implementations?

[Manuel M T Chakravarty]

Simon Marlow:
> On 24 April 2006 15:08, kahl at cas.mcmaster.ca wrote:
> 
> > 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" #-}
> 
> I understand your reasoning, but I think it's wrong to name libraries in
> the source code.  Library names tend to be platform specific, and change
> from version to version.  Unlike header files, the package implementer
> can't easily wrap a library dependency in a local library.

Which is exactly the POW the FFI committee adopted - ie, the inclusion
of libraries was considered, but rejected on the grounds Simon explained
(who as we all know was part of that committee :)

> > 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.
> 
> The issue is whether the .h file is available to the client at all.
> Making it available might impose an unnecessary burden on the client,
> such as having to install a development package for an external library.
> 
> Actually it just occurred to me why using NOINLINE isn't the right thing
> here.  The compiler should be free to inline a foreign call that depends
> on a private header, as long as the header isn't required for
> compilation, such as when using the native code generator.

Ah!  That's a good point.

Manuel