Abstract FilePath Proposal

[Herbert Valerio Riedel]

On 2015-06-27 at 03:30:56 +0200, Bardur Arantsson wrote:

[...]

> I am *entirely* behind this in priciple and if it doesn't break too much
> of Hackage, also in practice, but...
>
> ... how much of Hackage *does* this break?

This won't be for free: I expect most packages which currently do more
than just opaquely pass around FilePaths to require fixes.

Some examples:

 - `writeFile "doo/foo.bar" ...`
   `_ <- readFile ("doo" </> "foo" <.> "bar")`

   This will break unless -XOverloadedStrings happens to be enabled

 - Unless we generalise (++) to (<>), all cases where `FilePath`s are
   concatenated via (++) will break.

 - Code that uses Data.List rather than the `filepath` package for
   FilePath manipulation will need fixups (simplest fix: explicitly
   convert to/from String for the manipulation)

 - Some code, like e.g.

     fnames <- System.Environment.getArgs
     forM fnames $ \fn -> print =<< readFile fn

   will inevitably need to insert explicit conversions to/from FilePaths

I tried to simulate the effect on Hackage, but this turned out to be
more time-demanding than I hoped for and I had to abort. But the above
is what I encountered in my attempt.

> The reason that I'm in favor in principle is that paths really *are*
> opaque things -- platforms have entirely different conventions. AFAICT
> the only thing that they seem to agree on is that there is a "hierarchy"
> of some sort. (And not much else, including such things as case
> (in-)sensivity or character sets.).

> For example, in POSIX they're just strings of bytes without any
> specified encoding, and I'd love if they could be make to work like
> that when dealing with files in Haskell.

Yes, if you look e.g. at

  http://hackage.haskell.org/package/unix

you see a lot of API duplication, which wouldn't have been needed if
FilePath was an opaque type w/ lossless conversion to/from
ByteString.