FFI progress

[Marcin 'Qrczak' Kowalczyk]

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.

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 at knm.org.pl http://qrczak.ids.net.pl/
 \__/
  ^^                      SYGNATURA ZASTÊPCZA
QRCZAK