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.
_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
