[EMAIL PROTECTED] (Marcin 'Qrczak' Kowalczyk) wrote,
> Wed, 28 Mar 2001 12:10:46 -0700, Alastair Reid <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]> 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
_______________________________________________
FFI mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/ffi
