Updates to FFI spec

Simon Marlow simonmar at microsoft.com
Mon Aug 12 05:18:07 EDT 2002

> >> - I'd like to see a standard way to call the GC from C
> >> 
> >> http://www.mail-archive.com/ffi@haskell.org/msg00565.html
> >> 
> >> Note that Hugs and GHC have had this for ages except that we call
> >> the function 'performGC' and there's no way to control how many
> >> generations are collected.
> > I don't have a strong opinion on this one.
> Maybe SimonM and Malcolm do.  
> I know GHC has an interface already and I suspect that NHC will too.
> GHC and Hugs both call it performGC but this doesn't match the naming
> convention used in the ffi and it is expensive to use with
> generational GC (since there is no way to indicate that a partial GC
> may be enough).

System.Mem.performGC does a major GC.  When would a partial GC be

Isn't the property you really want "a full garbage collection has been
performed and all finalizers have been run to completion"?  Note this
would be non-trivial to implement in GHC.  We currently don't
distinguish between finalizer threads and normal threads, preferring to
leave it to the programmer to implement any synchronisation on
finalizers using MVars.

> >> - I see the question of Function prototypes as a portability
> >> problem waiting to happen.  Either Hugs and GHC are right (you
> >> should use the user-supplied header file or NHC is right (you
> >> should ignore the header file).  They can't both be right if we
> >> want portable code so the report should be clear about which one is
> >> right.

I think the spec should be clarified along these lines:

  Header files have no impact on the semantics of a foreign call,
  and whether an implementation uses the header file or not is
  implementation-defined.  Some implementations may require a header
  file which supplies a correct prototype for the function in order
  to generate correct code.

I'd be equally happy (perhaps happier) if the header file spec was
removed altogether.  In a sense, this would leave the Haskell part of a
foreign binding even more portable, because it doesn't have to specify
the names of header files which might change between platforms.  There
are already "external" parts of a binding such as the names of link
libraries, I think I'm arguing that header files also fall into that

> >> - Changes to hs_init
> >> 
> >> http://www.mail-archive.com/ffi@haskell.org/msg00539.html
> > I am ok with that.  Currently, there is a problem with the version
> > that is in the spec and GHC in that GHC requires an extra argument
> > to initialise modules.  So, it all depends a bit on how far SimonM
> > thinks its implementable.
> Hugs doesn't have anything resembling hs_init at the moment so I can't
> say for sure.  I think it can be done as a thin layer on top of the
> the existing spec though so I don't think it's that hard.

Perhaps on GHC you should be required to "register" the top module in
your program first, maybe something like


that way you can register multiple modules (which isn't possible at the
moment, you have to have another module which imports all the others).


More information about the FFI mailing list