> >> - 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 _______________________________________________ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi
