Fork chrisdone's path library
I wasn't happy with the way it dealt with Dir vs File things. In his
version of the library, a `Path b Dir` always ends with a trailing
path separator and `Path b File` never ends with a trailing path separator.
IMO, it is nonsensical to make a Dir vs File distinction on path level,
although it first seems nice.
Some of the reasons are:
* a path is just that: a path. It is completely disconnected from IO level
and even if a `Dir`/`File` type theoretically allows us to say "this path
ought to point to a file", there is literally zero guarantee that it will
hold true at runtime. So this basically gives a false feeling of a
type-safe file distinction.
* it's imprecise about Dir vs File distinction, which makes it even worse,
because a directory is also a file (just not a regular file). Add symlinks
to that and the confusion is complete.
* it makes the API oddly complicated for use cases where we basically don't
care (yet) whether something turns out to be a directory or not
Still, it comes also with a few perks:
* it simplifies some functions, because they now have guarantees whether a
path ends in a trailing path separator or not
* it may be safer for interaction with other library functions, which behave
differently depending on a trailing path separator (like probably shelly)
Not limited to, but also in order to fix my remarks without breaking any
benefits, I did:
* rename the `Dir`/`File` types to `TPS`/`NoTPS`, so it's clear we are only
giving information about trailing path separators and not actual file
types we don't know about yet
* add a `MaybeTPS` type, which does not mess with trailing path separators
and also gives no guarantees about them... then added `toNoTPS` and
`toTPS` to allow type-safe conversion
* make some functions accept more general types, so we don't unnecessarily
force paths with trailing separators for `(</>)` for example... instead
these functions now examine the paths to still have correct behavior.
This is really minor overhead. You might say now "but then I can append
filepath to filepath". Well, as I said... we don't know whether it's a
"filepath" at all.
* merge `filename` and `dirname` into `basename` and make `parent` be
`dirname`, so the function names match the name of the POSIX ones,
which do (almost) the same...
* fix a bug in `basename` (formerly `dirname`) which broke the type
guarantees
* add a pattern synonym for easier pattern matching without exporting
the internal Path constructor
8 years ago |
12345678910111213141516171819 |
- # HPath libraries
-
- [![Gitter chat](https://badges.gitter.im/Join%20Chat.svg)](https://gitter.im/hasufell/hpath?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge) [![Build Status](https://api.travis-ci.org/hasufell/hpath.png?branch=master)](http://travis-ci.org/hasufell/hpath)
-
- Set of libraries to deal with filepaths and files.
-
- ## Motivation
-
- * filepaths should be type-safe (absolute, relative, ...)
- * filepaths should be ByteString under the hood, see [Abstract FilePath Proposal (AFPP)](https://gitlab.haskell.org/ghc/ghc/wikis/proposal/abstract-file-path)
- * file high-level operations should be platform-specific, exception-stable, safe and as atomic as possible
-
- ## Projects
-
- * [![Hackage version](https://img.shields.io/hackage/v/hpath.svg?label=Hackage)](https://hackage.haskell.org/package/hpath) [hpath](./hpath): Support for well-typed paths
- * [![Hackage version](https://img.shields.io/hackage/v/hpath-filepath.svg?label=Hackage)](https://hackage.haskell.org/package/hpath-filepath) [hpath-filepath](./hpath-filepath): ByteString based filepath manipulation (can be used without hpath)
- * [![Hackage version](https://img.shields.io/hackage/v/hpath-directory.svg?label=Hackage)](https://hackage.haskell.org/package/hpath-directory) [hpath-directory](./hpath-directory): High-level IO operations for files/directories on raw ByteString filepaths (use hpath-io for the type-safe path version)
- * [![Hackage version](https://img.shields.io/hackage/v/hpath-io.svg?label=Hackage)](https://hackage.haskell.org/package/hpath-io) [hpath-io](./hpath-io): High-level IO operations for files/directories utilizing type-safe Path
- * [![Hackage version](https://img.shields.io/hackage/v/hpath-posix.svg?label=Hackage)](https://hackage.haskell.org/package/hpath-posix) [hpath-posix](./hpath-posix): Some low-level POSIX glue code that is not in 'unix'
|