control over the scope of C implementations?

[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.

> 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.

Cheers,
	Simon