On Fri, Mar 16, 2007 at 09:44:26AM +1100, Duncan Coutts wrote:
Of course if a module is still maturing and in a state of flux then adding it to base wouldn't be a good idea as one could not promise API stability. System.FilePath doesn't seem to be in that situation however, in my opinion it's ok to go into base (and come out again if/when base gets split up).
I think that's roughly the argument you made for FPS, but looking at the repo history there are at least these API changes since the GHC 6.6 release: * export the right 'cycle' * Add a unit tests file, a test that append is lazy in the tail, and make it so. * "HEADS UP: Change CString api" * Make the lazy cons lazy, and add a cons' for when you want it to be strict * Make fromForeignPtr take the start so it is truly the inverse of toForeignPtr * Define headTail :: ByteString -> Maybe (Word8, ByteString) Sure, all of these can be worked around by importing internal modules and copying the corrected definitions (as I have had to do), but it would be much simpler if I could just depend on bytestring >= 1.1. Thanks Ian