FFI progress

Manuel M. T. Chakravarty chak at cse.unsw.edu.au
Wed Mar 28 22:53:37 EST 2001


qrczak at knm.org.pl (Marcin 'Qrczak' Kowalczyk) wrote,

> Wed, 28 Mar 2001 12:10:46 -0700, Alastair Reid <reid at 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 at 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




More information about the FFI mailing list