FilePath modification proposal

[Neil Mitchell]

Hi,

As maintainer, it's kind of a grey area if I need to make proposals
for the filepath library, but since I'm a relatively new active
maintainer for a Core library, I thought I'd err on the side of
caution. Please yell if you think these are a bad idea, otherwise I'll
just do them (probably over the next few weeks).

* Change 1: Add -<.> as an alias for replaceExtension with the same
precedence as <.>

This change has been in Shake for a while now, and seems generally
useful. It isn't an operator in the lens library, and it reads nicely
as a combination of - (remove something) and <.> (addExtension). The
argument order of replaceExtension is a bit unfortunately, since
replace functions usually have the thing to replace with first, but
since extensions are at the end of the FilePaths that suggests making
it the second argument (which is what filepath does). In contrast,
-<.> has a very obvious argument order.

* Change 2: Stop testing as part of GHC

The test suite is complicated enough, since it generates code from the
doc comments. Having the test suite also run by GHC complicates things
further, since it has to integrate with the GHC test suite environment
with extra Makefiles etc. Since August 2011 the FilePath test suite
actually passes even if you break the properties (oops!) so it's
provided no value at all in the last 3 years.

In general, running all the tests in all the places is a good thing.
But I think filepath is a bit different given it's exclusively
cross-platform string manipulations, so I don't think its runtime
behaviour is version/platform sensitive in any way. I also develop on
Windows with 4 versions of GHC, and Travis tests it on Linux with 6
versions of GHC. That seems sufficient test coverage.

* Change 3: Check in the generated test code

If you check out the filepath repo it won't build - you have to run
some code to generate the tests first. That's a barrier to entry, and
makes testing with GHC harder. I'm increasingly starting to believe
that for a small number of small files where the generator ships with
the code, it's easier to check in the generated code and then have
Travis run the generator and check nothing changes. It's easier to get
started, easier to debug when things change, and the only real cost is
a few extra checkins.

Thanks, Neil