qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk) wrote,
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.
I have usually not needed an extra (custom) header file associated with Haskell modules, but maybe the libraries that bound where just exceptionally well behaved. "Alastair Reid" <reid@cs.utah.edu> wrote,
foreign import "<foo.h>,<bar.h>:f" f :: <type> foreign import "<bar.h>,<foo.h>:f" g :: <type> Should I report an error?
Or, suppose I have:
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?
(When answering, remember that an optimising compiler might combine code from multiple modules (possibly with multiple maintainers) into a single C source file due to cross-module inlining.)
That's a very good argument in favour of SimonPJ's proposal,
Its easy to add features and nigh impossible to remove them. I suggest we have just
"gtk:foo"
(no ".h") meaning #include "gtk.h" Now we can sensibly interpret "gtk:foo" as meaning "foo from package gtk"; and in concrete terms import a suitable header file.
Ok. I think, this scheme is sufficient and Alastair has pointed out the semantic difficulties of a more complex scheme. Moreover, Marcin seems to favour it, too. Any objections? Manuel