FFI digest, Vol 1 #218 - 3 msgs

[Alastair Reid]

> 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                 alastair at reid-consulting-uk.ltd.uk  
Reid Consulting (UK) Limited  http://www.reid-consulting-uk.ltd.uk/alastair/