Hi Bulat,
I note that the deadline for discussion of System.FilePath has now passed (well, a long time ago :-), so it looks like it's going into base. Any final objections before we do this?
The deadline passed before Christmas, and no one objected. I still intend to move it in to base,
may be it is a good time to start File library? i has some ideas for it, and also want to propose it as SoC project. just a couple of ideas:
- ghc rts independent i/o lib - portable async i/o which is able to work via select/epoll/... - support for unicode filenames - String/ByteString/UTF8String as filename - filepath operations (your module) - filesystem operations (System.Directory) - support for large files (>4gb) on windows - bytestring i/o - interfacing with Streams and FPS libraries
These are all worth thing to do, but there are two different type of operations here - those that operate on filenames, and those that do IO. As Simon Marlow has previously said, keeping these things separate is usually a good idea. This also seems to be an attempt to replace type FileName = - something that is going to take much more work. Rolling my FilePath code into this package is perfectly fine, but I think the FilePath operations specialised to String (as defined by Haskell 98) are important to go into base, if for no other reason than without them Cabal cannot depend on them. I realise you are trying to split up the base library, but Cabal requires it keep to be kept intact just a little bit longer ;) Thanks Neil