Alastair Reid wrote: [snip]
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. I don't believe it's at all simple to specify that Haskell-land may not be invoked at any time during the duration of some C function. I'm not even sure I know what "duration" means, in the presence of concurrency.
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. People who only call C in a fairly simple way can still port their FFI code between Hugs, GHC and NHC. We all know that the current mechanism is a huge improvement on the old non-portable ones. However anyone who goes beyond this needs to be aware of elephant traps, and we should not expect them to read the specification in detail to do so.
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. You also need entrypoints into (say) the Java runtime system, if you are going to interact with Java. Otherwise how are you going to tell Java that one of your Haskell-provided callbacks must be delayed until Hugs has finished its garbage-collection? Or are you proposing that anyone linking Hugs with Java must implement a lock (in Java) which blocks every single callback to Hugs during Hugs GC's?
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.
The difference is that the "unsafe" calling convention uses the word "unsafe". People who use features which are labelled "unsafe" may be assumed to be aware of the elephant traps in the specification. If they aren't it's their own fault. The reason most calls at the moment are unsafe is because the FFI has mostly been used to link directly to C code in a fairly single-threaded way. I'm not sure even this is a good idea, since we can't go on assuming a single native thread for much longer. [snip]