The filepath
package provides functionality for manipulating FilePath
values, and is shipped with both GHC and the Haskell Platform. It provides three modules:
System.FilePath.Posix
manipulates POSIX/Linux styleFilePath
values (with/
as the path separator).System.FilePath.Windows
manipulates Windows styleFilePath
values (with either\
or/
as the path separator, and deals with drives).System.FilePath
is an alias for the module appropriate to your platform.
All three modules provide the same API, and the same documentation (calling out differences in the different variants).
The answer for this library is "no". While an abstract FilePath
has some advantages (mostly type safety), it also has some disadvantages:
- In Haskell the definition is
type FilePath = String
, and all file-oriented functions operate on this type alias, e.g.readFile
/writeFile
. Any abstract type would require wrappers for these functions or lots of casts betweenString
and the abstraction. - It is not immediately obvious what a
FilePath
is, and what is just a pureString
. For example,/path/file.ext
is aFilePath
. 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 usefoo//bar
for globs, which is definitely not a file, but might want to be stored as aFilePath
. - Some programs use syntactic non-semantic details of the
FilePath
to change their behaviour. For example,foo
,foo/
andfoo/.
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 manipulatingFilePath
values like lists. This library hopes to help in that effort.