FFI Definition

[Simon Marlow]

> Simon PJ writes:
> > I thought we agreed to remove the specification of 
> libraries from the
> > FFI, and leave it to some compiler-dependent mechanism.  As 
> Sven points
> > out, there are going to be times when you really don't want 
> a library at
> > all, or in any case not one with the same name as the 
> header file, and
> > there will be cases where you want several libraries in some
> > system-dependent order that shouldn't be placed in the source code.
> 
> I'm certain that at least one person (me) disagreed with removing any
> library specs from the FFI.  I tend to the view that if the compiler
> needs to know about something (and can't work it out for itself) the
> information should be in the source code.  Putting it in a Makefile
> or some other auxiliary structure (package configuration?) is not
> really clean enough for me.  I don't want to have to write three
> different Makefiles, one for each possible compiler I could use.
> Please let's aim for portability.
> 
> Having said that, it is true that the FFI may not be the best place
> for a specification of link libraries or whatever.  Maybe we should
> agree on some pragmas for this sort of information?  In any case,
> I'd like to have a compiler-independent standard, whether or not it
> is part of the FFI.

The reason for not putting them in the source is because the names of
libraries change from system to system but their APIs don't.  It's
possible to write a portable binding to an API if you don't have to
include the libraries,  but including the library names requires
information from the system, which is normally picked up by a configure
script.

For example, what should I link to in order to get GLib?  On the RedHat
system here, it's -lglib, but on my FreeBSD box at home it's -lglib12,
but the code for the binding remains the same.  So to keep the Haskell
code portable, it should omit the library names.  I see the information
in a package config as "meta-information" about the Haskell code:
information about the particular environment in which the code is
running.  It's certainly not a perfect separation, because some
system-specific things have to be compiled into the code to get decent
performance (the values of the errno constants, for example), but at
least it leaves the Haskell code independent of filenames and directory
locations.

If you want to put this information in a pragma for NHC that's fine.
I'd much prefer to see NHC use our package scheme though:  I'll be happy
to incorporate any changes needed by NHC into the tools.

Cheers,
	Simon