I think adding new (hierarchical) modules is the way to go for now.
1) Hierarchical because it lets us use some nice clear
module naming style like:
Foreign.NonStd.*
or
Foreign.Extension.*
[I favour the former since the status of the lib is clearer.]
I'm a bit uncertain over how many modules should live in
this new hierarchy. The easy answer is just one - by the time
we have more than a module's worth of code, it's time to
add some of them to the standard. An alternative is to mirror
the structure of the standard libs:
Foreign.NonStd.{C,ForeignPtr,Marshal,..}
which would be useful if we don't want to bump the ffi version
number too often.
2) I think the evolution of the ffi std from Sigbjorn's original
foreign import/export proposal benefited hugely from things like
the QForeign library where ideas could accumulate and become
consistent, portable, etc.
3) We don't have any way to do version numbered packages at
present but we need somewhere to put the code now.
--
Alastair
[Detail: The GHC folk might want to move Foreign.Concurrent to
Foreign.NonStd.Concurrent.]
_______________________________________________
FFI mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/ffi
