Updates to FFI spec

[Simon Marlow]

> >> - 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
enough?

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
category.

> >> - 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

	registerModule(__stginit_Main);

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).

Cheers,
	Simon