Proposed change to ForeignPtr

Manuel M T Chakravarty chak at cse.unsw.edu.au
Thu Sep 5 04:36:33 EDT 2002


Alastair Reid <alastair at reid-consulting-uk.ltd.uk> wrote,

> [Now that we've gotten the library specification issue out of the way,
> I'd like to revive discussion of this topic.  Last time we discussed
> it, there seemed to be concensus that we would make a change but I
> didn't get much response when I made a concrete proposal.  I'd like to
> resolve this promptly so that the impending Hugs release can match
> what the spec says (or vice-versa...).]
> 
> Since requiring ForeignPtr.newForeignPtr would require preemptive
> concurrency (see previous discussion), I propose the following changes:
[..]

I thought we have settled this already.  See my appended
email from three weeks ago.  The only reason I haven't
changed it in the spec yet is that I wanted to give people
time to object.  Nobody has.  So, I would deem this
accepted (reusing the old function names btw).

Manuel

-=-

Subject: Re: Proposed change to ForeignPtr
From: Manuel M T Chakravarty <chak at cse.unsw.edu.au>
To: ffi at haskell.org
Date: Mon, 12 Aug 2002 23:00:22 +1000 (EST)
Reply-To: chak at cse.unsw.edu.au
X-Mailer: Mew version 2.2 on XEmacs 21.4.6 (Common Lisp)

We seem to have a consensus on this one.  We change the type
of the existing functions to

  newForeignPtr :: Ptr a -> FunPtr (Ptr a -> IO ()) -> IO (ForeignPtr a)
  addForeignPtrFinalizer :: ForeignPtr a -> FunPtr (Ptr a -> IO ()) -> IO ()

For GHC, I propose to put the closure-based versions into an
extra module (that's easy enough with the hierarchical
libraries).  This makes changing over old code easier, as it
merely requires to alter the import and not all occurences
of the functions.

Any objections?

Cheers,
Manuel
_______________________________________________
FFI mailing list
FFI at haskell.org
http://www.haskell.org/mailman/listinfo/ffi



More information about the FFI mailing list