Simon Marlow <simonmar@microsoft.com> wrote,
Ok folks, I decided it's time we woke this list up again.
*kick*
:-)
Right. I've got so many things on my ToDo list that come under the heading of "can't be done until the FFI library is finalized", it's getting silly.
Once this session is over - in a bit more than a month - the FFI library is at the top of my priority list.
STEP 1: Addr or (Ptr a) ?
I'm convinced that Ptr a is the way to go. After brief conversations with Manuel at ICFP, I think he's agreed
Definitely!
Using "Ptr a" eliminates the need for those annoying dummy arguments to malloc and friends, and provides some useful type safety. It might also in the future allow us to typecheck our FFI calls with respect to the foreign interface, but there are still issues to resolve before this can happen.
You are right that it is still open how far we can push `Ptr a', but I think, the benefits that we already know are convincing enough.
I've enclosed my modified version of GHC's Storable module, and a new module Ptr containing the definitions of Ptr and FunPtr (ripped from Marcin's library mostly). Comments are most welcome.
Re Storable: - So, it is decided to nuke AddrOff? - mallocArray/mallocBytes Versus mallocElems: Isn't mallocBytes redundant? mallocArray on Word8 should be the same, shouldn't it? Re Ptr: - Why call it `ptrPlusBytes' when there is no other `ptrPlus'? (I could imagine one, which adds multiples of the size of the `a' in `Ptr a'.) - Would `freeHaskellFunPtr' replace `IOExts.freeHaskellFunctionPtr'? Otherwise, this is all perfectly fine with me. Cheers, Manuel