Simon Marlow:
> On 24 April 2006 15:08, [EMAIL PROTECTED] 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
_______________________________________________
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime
