cvs commit: fptools/libraries/base/Foreign/C Error.hs fptools/libraries/base/System/Posix Internals.hs fptools/libraries/network /Network Socket.hsc

[Simon Marlow]

=20
> I've never been overly keen on GHC's use of pragmas containing extra
> command line arguments for GHC because they seem to be about just one
> way of compiling the code (that is, they are compiler specific and,
> sometimes, backend specific) so they don't seem to really belong in
> source code.

We primarily use OPTIONS pragmas to specify options that describe the
nature of the source code in the module.  For example, -fglasgow-exts
says that this source file contains code written in Haskell + GHC
extensions.  The source code is exactly the right place for this option
to go.

Admittedly, OPTIONS should be called GHC_OPTIONS.  Even better, we
should use a compiler-independent way to specify the language flavour in
the source file, eg. {-# LANGUAGE ffi, ghc #-}, which would also give
other compilers a chance to complain if they don't support that
particular language variant.

OPTIONS is also used to specify #includes for the C back-end.  The
source code is the right place for these too, but the use of OPTIONS is
a little clunky.  We *could* add these to the FFI declarations instead,
but (a) it's verbose (you have to add the #include to every foreign
import that needs it) and (b) GHC doesn't support it very well.

> The CBITS pragma doesn't have the more obvious problems of the GHC
> mechanism (e.g., the contents of the pragma are unlikely to have to
> change from one version of Hugs to another) but it feels similar
> enough to make me a little uneasy.
>=20
> So I guess I'm asking:
>=20
> 1) Are there other design options?
>=20
> 2) Can the problem of associating C files with Haskell ffi files
>    be solved in a way that all compilers (and associated tools,
>    makefiles, etc.) can support and exploit?
>=20
>    (e.g., other compilers support the CBITS pragma, or an ffi
>    extension, or a package configuration file extension, or a text
>    file which can be read both by GHC makefiles and by your package
>    conversion script, etc.)

I have a feeling that there are enough differences between the way Hugs
works and the way GHC works to make trying to unify these things
awkward.  I suppose you could add something to the package spec which
lists C files and the libraries they should be linked into - but unless
you can put *all* the information into the package spec (i.e. leaving a
completely generic Makefile / conversion script etc.) it doesn't really
buy you very much.

This brings us back to having a decent library-building infrastructure.
My vote would be to do all this in the infrastructure, centralising the
knowledge about the differences between compilers.

Cheers,
	Simon