Sat, 2 Dec 2000 13:13:08 +1100, Fergus Henderson <fjh@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@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK