Updates to FFI spec

[Alastair Reid]

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

>> - 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.
>> 
>> (Given my druthers, I'd drop header files from the foreign import
>> syntax and say that you have to specify it on the command line or
>> propose that we standardize some variant of the GHCism {-# -include
>> "foo.h" #-}.  But I'm not excited enough about it to push hard for
>> this.)

> I am still in favour of user-supplied header files and the mechanism
> as it is defined in the spec right now.

Malcolm and I both found it possible to interpret the spec as meaning
that the header files could be ignored.  If that isn't what the report
means, the wording should be strengthened.


[My concern with specifying header files in foreign imports is twofold:
1) It suggests the existence of multiple namespaces when I very much
   doubt that anyone would every implement that.
2) It is awfully repetitive because you have to mention the header files
   on every foreign import just in case anyone ever did implement
   multiple namespaces.  (Other side of the same problem.)
I'm not arguing for a change here - just saying that I wouldn't argue
against one.]


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

--
Alastair Reid                 alastair at reid-consulting-uk.ltd.uk  
Reid Consulting (UK) Limited  http://www.reid-consulting-uk.ltd.uk/alastair/