On Fri, 2007-03-16 at 02:55 +0000, Ian Lynagh wrote:
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.
So some of these are just bug fixes and not api changes so will be in 6.6.1. But in general: so you could say that these bugs show we should have waited longer for the library to mature, on the other hand I rather suspect that we'd never have found these without the huge number of people using the lib that came from it being included as standard. That was not the only reason to include it of course. As I've mentioned before, a reason to keep it in base in future is that it gives us the opportunity to rewrite programs that don't even import ByteString into more efficient versions, for example: f . lines =<< readFile "foo" to f . map unpack . B.lines =<< B.readFile "foo" (and there may be further fusion opportunities if f is a fusible list consumer) Duncan