Re: Abstract FilePath Proposal
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.
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 :)) Regards,
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
On 2015-06-27 at 14:11:52 +0200, amindfv@gmail.com wrote: [...]
- `writeFile "doo/foo.bar" ...` `_ <- readFile ("doo" "foo" <.> "bar")`
This will break unless -XOverloadedStrings happens to be enabled
[...]
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)
That's right; w/o OverloadedStrings, you'd have to write e.g. writeFile (toFilePath "test.txt") "test" (which will be possible to write as soon as `filepath` starts exposing the forward-compat `{to,from}FilePath` conversion functions)
participants (4)
-
amindfv＠gmail.com -
Bardur Arantsson -
Herbert Valerio Riedel -
Herbert Valerio Riedel