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

[Manuel M T Chakravarty]

Ross Paterson <ross@soi.city.ac.uk> wrote,

> On Mon, Apr 14, 2003 at 11:53:58AM +0100, Simon Marlow wrote:
> > 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.
> 
> This one is a bit of a pain.  Some library modules have several -#include
> options.  To turn that into code that conforms to the FFI spec, you have
> to collect those #include's in a new header file, and add that to each
> of the foreign imports; if those already have includes, more munging
> is required.
> 
> If you've decided that the method provided by the FFI spec (though
> sufficient) is too clunky to use, perhaps it should be changed.

We have discussed this particular point for a quite a
while.  The conclusion was that it is infeasible to provide
the flexibility of CPP; hence, the FFI just provides the
bare minimum and anything more complicated requires the
programmer to write a custom header and include that in the
FFI declarations.

What I am curious about is point (b).  In what respect does
GHC not support it well?

Cheers,
Manuel