Hi FFI people.
Here are some of my comments about the latest ideas being discussed,
grouped together in one message.
----
Re: Marcin's high-level marshalling library
> > So, maybe you can briefly comment on whether your current code
> > stays within Haskell 98 or not.
> It only relies on multiparametric type classes.
As Manuel already pointed out, MPTCs are not Haskell'98, and are
very unlikely to be supported by nhc98 or hbc.
But SimonM's idea of having two layers - a lower layer using H'98+FFI,
and an upper layer using MPTC and other possible Haskell-2 features
seems workable.
----
Re: keeping ForeignObjs alive after doing foreignObjToAddr
> touch :: ForeignObj -> IO ()
It looks good to me (provided you can prevent GHC from optimising
it away).
> In fact, having `touch', we could get rid of the condition
> impossed by the last bulleted item on the page
> http://haskell.cs.yale.edu/ghc/docs/latest/set/sec-primitive.html
> This condition basically requires the implicit introduction
> of a `touch' by the compiler and so is redundant if we have
> an explicit `touch'.
Well as you know I always had a problem with that condition anyway :-)
It is only a reminder to a clever optimising compiler that normally
throws things away as soon as possible, in this case not to throw
it away. A non-clever compiler like nhc98 holds onto primitive
arguments throughout the call anyway without any special trickery
needed.
But I agree with SimonM that:
> the behaviour where the ForeignObj stays live across the call is
> normally what you want; requiring that an explicit touch be used is
> too fragile.
And to Manuel's remark:
> Hehe - just forbid passing ForeignObjs as parameters to
> external functions. This would force everybody to use
> foreignPtrToAddr, which again would make the need for touch
> more obvious.
Well, I can see that (in principle) it is entirely reasonable to
get rid of ForeignObj altogether, replacing it with an ordinary
`Ptr a' and an `addFinaliser' to attach a weak pointer to it.
But as the FFI stands at the moment, ForeignObjs are standard, and
weak pointers aren't. So yes, we just have to live with the cruft
of having to remind clever compilers to be a little bit less clever
in certain places. :-)
----
Re: weak pointers in nhc98
> No, addFinaliser in Gtk+HS code until it is part of the
> portable (ie, no GHC-specific) FFI, please. I want Gtk+HS
> also to run with NHC (main obstacle was a bug preventing me
> to compile C->HS so far - and lack of time to try whether
> that was fixed in recent time).
Manuel, I'm not sure whether you meant "No, addFinaliser" or
"No addFinaliser" (without the comma) - their meanings are opposite!
But you are right that nhc98 does not have a Weak Pointer library.
If the library were implemented purely through the FFI without
requiring additions to the runtime system, it could be added without
problems, but I think that probably isn't possible.
Sorry I haven't had time recently to check whether C->HS works in
nhc98 currently either!
> Simon, could you give us an idea how easy or difficult it
> would be to implement addFinalizer without having all of
> weak pointers?[1]
> [1] Malcolm, do you have any comments on addFinalizer as
> part of the core FFI?
I didn't fully understand Simon's answer to this, but my impression
is that addFinaliser probably needs a full implementation of weak
pointers.
----
Re: temporary allocation functions
> withForeignObj :: ForeignObj -> (Ptr a -> IO b) -> IO b
>
> From a users point of view, I like these functions that
> basically delimit a block by having the stuff in the block
> as a higher-order function.
Me too. I like the `withForeignObj' name as well.
----
Regards,
Malcolm
