ForeignPtr naming

[Manuel M T Chakravarty]

"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".

Cheers,
Manuel