> I agree that it's extremely unsatisfactory, but it seems the best > option (to me) of defining it is not going to be accepted. So at > least it would be better if GHC's documentation said "We implement > the FFI" while Hugs and NHC's said "We implement the FFI with the > caveat that finalizers may not call back into Haskell, as specified > in section [blah]".
I maintain that it is better to specify something simple and for GHC to document that it goes beyond the specification just as it does for unboxed types and the like. What's the point in going to all the effort of coming up with a common specification, all of us hacking our implementations to match the spec, endless arguing over details of the syntax, types, libraries, etc. if it doesn't achieve the goal of improving portability? It would have been much easier if we'd left our (incompatible) implementations alone and not made an effort at defining a portable ffi spec. > Since I regard this caveat as an extremely > important one (for example, it severely limits the use of the FFI to > link to languages like Java, which also have their own GC) I just want to note that I believe what you really need is a bunch of entrypoints into the runtime system not the ability to call Haskell code. > it needs to be stated very clearly in the documentation of those > implementations which have it, rather than being left as an > embarassing hole which the user will only discover after a long and > painful analysis of the core-dumps. Note that the problem is _exactly_ the same problem faced when using foreign functions which were declared using the 'unsafe' calling convention. The only difference I can see is that unsafe calls are much more common so they are more of a problem. As I was implementing the unsafe stuff in Hugs, it occurred to me that I could probably dynamically detect when an unsafe function (i.e., one which the user promises is not reentrant) performs a reentrant call. The idea is that on making an unsafe call, we set a bit saying that reentrancy is not allowed and on calling into a foreign exported function or performGC we check whether the bit is set. Making this work in a multithreaded setting like GHC would be more painful and more expensive but probably feasible. -- Alastair Reid [EMAIL PROTECTED] Reid Consulting (UK) Limited http://www.reid-consulting-uk.ltd.uk/alastair/ _______________________________________________ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi
