Manuel M T Chakravarty
chak at cse.unsw.edu.au
Thu Mar 20 20:50:48 EST 2003
"Simon Marlow" <simonmar at microsoft.com> wrote,
> > > I'm assuming that we want to keep these functions in some form in
> > > GHC - where to put them is one issue; Foreign.ForeignPtr is a
> > > possibility (but not ForeignPtr), or GHC.ForeignPtr.
> > I'd put them in GHC.ForeignPtr and make no other change in their name.
> One vote for GHC.ForeignPtr then. Any others?
> > Easy for people to transition, easy for people to see non-portable
> > code, probably little risk of collision with the ffi-mandated FunPtr
> > versions.
> On the subject of non-portability: the hierarchy is scattered with
> non-portable libraries, because the decision was taken a while back not
> to use the hierarchy to indicate portability, but to use it to guide
> programmers towards *functionality*. There are exceptions - eg. for
> extensions which are likely to remain compiler-specific. I don't think
> Haskell finalizers are necessarily GHC-specific, so putting them under
> GHC doesn't seem right in the long term.
As Haskell finalizers need pre-emptive concurrency, maybe
they should go somewhere related to concurrency. Or we
could have a "Foreign.Concurrent".
More information about the FFI