[commit: packages/filepath] master: #12, note that this library helps move towards an abstract filepath type (10553c6)

[git at git.haskell.org]

Repository : ssh://git@git.haskell.org/filepath

On branch  : master
Link       : http://git.haskell.org/packages/filepath.git/commitdiff/10553c6bb145e9c29f5bece3db88c3904eb9cb91

>---------------------------------------------------------------

commit 10553c6bb145e9c29f5bece3db88c3904eb9cb91
Author: Neil Mitchell <ndmitchell at gmail.com>
Date:   Tue Dec 22 08:12:43 2015 +0000

    #12, note that this library helps move towards an abstract filepath type


>---------------------------------------------------------------

10553c6bb145e9c29f5bece3db88c3904eb9cb91
 README.md | 1 +
 1 file changed, 1 insertion(+)

diff --git a/README.md b/README.md
index 536f88c..6c3ca0c 100644
--- a/README.md
+++ b/README.md
@@ -16,3 +16,4 @@ The answer for this library is "no". While an abstract `FilePath` has some advan
 * It is not immediately obvious what a `FilePath` is, and what is just a pure `String`. For example, `/path/file.ext` is a `FilePath`. Is `/`? `/path`? `path`? `file.ext`? `.ext`? `file`?
 * Often it is useful to represent invalid files, e.g. `/foo/*.txt` probably isn't an actual file, but a glob pattern. Other programs use `foo//bar` for globs, which is definitely not a file, but might want to be stored as a `FilePath`.
 * Some programs use syntactic non-semantic details of the `FilePath` to change their behaviour. For example, `foo`, `foo/` and `foo/.` are all similar, and refer to the same location on disk, but may behave differently when passed to command-line tools.
+* A useful step to introducing an abstract `FilePath` is to reduce the amount of manipulating `FilePath` values like lists. This library hopes to help in that effort.