Hi, PROPOSAL I guess most people saw this coming, but here is the proposal to add System.FilePath to base. The System.FilePath module is located at http://www-users.cs.york.ac.uk/~ndm/projects/libraries.php#filepath In particular I propose the addition of System.FilePath (a cross-platform FilePath manipulation library), System.FilePath.Windows (Windows paths on all OS's) and System.FilePath.Posix (Posix paths on all OS's). The Version_* stuff is not being proposed for addition. Following the library submission guidelines: * Currency, I do not include a darcs patch, that can be done later - this is a stand alone module so currency is not a necessary criteria. The current module does not use CPP in a particularly nice way (so as to leave the primary module selecting its OS at runtime). The code that would actually be committed will be functionally identical, but slightly faster. If people agree to everything else I'm happy to wave a patch past people before the final committing. * Portability, Windows+Linux, GHC+Hugs+Yhc * Style, not applicable to adding a new module. The module is clean and well implemented, by most style guidelines. * Documentation, detailed - see the haddock link above * Tests, very thorough, over 200 tests/properties DISCUSSION Since the people who hang out on the libraries list may not include all the people who have previously commented on the FilePath module in previous versions, I have CC'd some of these people (particularly those with a strong opinion), so as not to exclude anyone from the discussion. If these people want to continue to discuss System.FilePath they should probably join the libraries list for the time being. Since this module has had extensive comments on it previously, I have attempted to summarise some of the reasons that people have given against the inclusion of these modules, along with the basic counter arguments. This is just an attempt to give some background to people new to the discussion - feel free to expand on any point, or raise new points etc - discussion welcome. 1 type FilePath = String is a bad design choice, which should not be encouraged * This is the way it is, Haskell 98 says so * This library allows better structuring of FilePath's, so makes the interface more abstract * This library makes a good attempt to be correct in it's transformations * We now have explicit properties for FilePath interaction - this isn't string hackery * Paves the way for an ADT, in the future (if desired) * Reverse compatible 2 The base libraries are not the place for a FilePath library * Setup.hs scripts will need it, and they only depend on base and Cabal * Could remove the version from Cabal * Encourages programmers to use it * FilePath functions are (very) easy to write wrongly * FilePath handling should have been present from the begining * It's already there internally, see System.Directory.Internals 3 The base libraries are being split up * This is something happening in the future * Put FilePath in, where it currently belongs, move it later * The FilePath library belongs with type FilePath, which belongs in base * If we ever move to an ADT, this library will have to be in base 4 The interface in this library is poorly designed * Repeated iterations in public have lead to a reasonable concensus * Clear and concrete properties given for all operations * If particular problems still remain there is some flexibility 5 Why not type FilePath = ByteString * If you argue for this, and for 1, you're not internally consistent! * It's not reverse compatible * This should be tackled as a whole thing, i.e. String defaulting * Not lazy I'll open a trac bug shortly. I suspect that there will be plenty of discussion, so I'd rather not set any time limit until everyone has had a chance to express their full opinion. However if we could try and wrap this up before Christmas that would be nice :) Thanks Neil