errno again

[Marcin 'Qrczak' Kowalczyk]

Sat, 2 Dec 2000 13:13:08 +1100, Fergus Henderson <fjh at cs.mu.oz.au> pisze:

> > 1. Is it possible to have the second kind from the level of the
> >    Haskell compiler at all (done in an sufficiently elegant way to
> >    think about it as a candidate proposal for the official FFI)?
> 
> I think so.

I hope that improvement there is possible, because even importing
plain C functions to ghc is not perfect:

- When using the native code generator, there is no type checking
  across languages at all.

- When compiling via C, the C function sometimes gets inlined in the
  interface file and called directly from other modules which did
  not include the C header. It results in a warning about implicit
  function definition (which is illegal in C99 BTW) and will not work
  at all for foreign labels.

So we don't really have a choice: there should be some notion of
a "C preprocessor and declaration environment" needed by a Haskell
module. It must be robust enough to make it possible to automatically
reproduce the environment for other modules which use the module
which introduces the environment.

Maybe it should not be transferred unnecessarily. When no C function
is inlined in an exported Haskell function, it does not buy anything
to transfer the C environment, and there is always the danger of
conflicts with other C headers.

One minor but annoying thing: when a function is declared in a C
header only when a given preprocessor symbol is defined, and the
header gets included automatically by ghc's rts, it is too late if
the symbol is defined e.g. in another C header which is included
using ghc's -#include option. It must be passed to ghc command line
as e.g. -optc-D_XOPEN_SOURCE. I'm afraid that such glitches may become
a pain if the machinery is automatized in a wrong way.

It will surely get worse when aiming at other languages :-)

-- 
 __("<  Marcin Kowalczyk * qrczak at knm.org.pl http://qrczak.ids.net.pl/
 \__/
  ^^                      SYGNATURA ZASTÊPCZA
QRCZAK