El Jun 27, 2015, a las 7:39, Bardur Arantsson
On 06/27/2015 09:54 AM, Herbert Valerio Riedel wrote:
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.
It could, of course, be argued that some of this is "deserved breakage" since blind concatenation (etc.) is probably already wrong in many cases.
(If someone is going to help fix up the breakage, then I'm still +1 :))
Just to be clear, every existing "creation" of a FilePath (without OverloadedStrings) will be broken, right? So e.g. 'writeFile "test.txt" "test"' will be just as broken as 'writeFile ("foo" "test.txt") "test"' (or the '++' version) I'm not +1 or -1 yet, just clarifying. Tom
Regards,
_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries