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

Reply via email to