Proposal: Add System.FilePath to base

[Neil Mitchell]

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