Pragmas for FFI imports

Simon Marlow simonmar at microsoft.com
Wed Feb 22 05:10:52 EST 2006


On 22 February 2006 01:33, John Meacham wrote:

> On Tue, Feb 21, 2006 at 04:50:20PM -0000, Simon Marlow wrote:
>> First of all, my position on this has always been (since we argued
>> about this during the design of the FFI) that include files and
>> libraries should be kept out of the source file and specified
>> separately, since they are a part of the build infrastructure, and
>> vary across platforms. 
>> 
>> I lost the argument for include files, but this is why libraries
>> cannot currently be specified inside source files.  Back in the FFI
>> discussion, we didn't have Cabal, but now that we do, Cabal is the
>> natural place to specify these things.
> 
> the problem is that package granularity is way to big for specifying
> dependencies, jhc wants all dependencies attached to each FFI import.
> the reason being that it collects only the dependencies for things
> that are actually used so for instance the following works:
> 
> foreign import ccall "fcntl.h open" c_unix_open ...
> foreign import ccall "win32.h OpenFile" c_win_open ...
> foreign import lvm "lvmOpen" c_lvm_open ...
> 
> 
> openFile = case os of
>         "unix" -> ... c_unix_open ...
>         "lvm" -> .... c_lvm_open ...
>         "win32" ->..  c_win_open ...
> 
> and all the intermediate code remains platform independent.

You could still break this into packages - I guess I'm not convinced by
the argument that packages have too large granularity.  It seems nice,
even, to put the OS-specific code into separate packages in this
example.

Cheers,
	Simon


More information about the Haskell-prime mailing list