Wed, 28 Mar 2001 12:10:46 -0700, Alastair Reid <reid@cs.utah.edu> pisze:
If most libraries could be ffi'd without the need for additional C files, the multiple header file notation would be an obvious win.
As it is, many libraries I've dealt with need one or more .c files containing some support code and, in that case, it's not too big a deal to add another file.
I think that since usually there is a C header associated with the module, it's not a problem to put original C headers there. I prefer minimal header information at each foreign declaration, so it would refer only to the custom module. hsc2hs fits into this model. The user can let it choose the right form for compilers supporting or not supporting the discussed feature, e.g. foreign import #{fun "Foo", "f"} unsafe f :: Type or better #module "Foo" foreign import #{fun "f"} unsafe f :: Type
foreign import "<foo.h>,<bar.h>:f" f :: <type> foreign import "<bar.h>,<foo.h>:f" g :: <type> Should I report an error?
No.
foreign import "<foo.h>:f" f :: <type> foreign import "<bar.h>:g" g :: <type> foreign import "<foo.h>:h" h :: <type>
can I assume that foo.h will only be included once? can I assume that foo.h is included before bar.h?
No. Since headers from multiple declarations can be put into one file, they may come in arbitrary order. You may get more headers than requested, but not less. Particularly the compiler is allowed to collect headers from all foreign declarations and attach them to the module itself, and to arbitrarily combine headers from various modules when C function calls are inlined across modules. The compiler is not forced to detect duplicates, but I would expect it to do so at least for declarations coming from a single module (so cpp doesn't need to process the header a hundred times). -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK