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.