Abstract FilePath Proposal

[amindfv at gmail.com]

El Jun 27, 2015, a las 7:39, Bardur Arantsson <spam at scientician.net> escribió:

> 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 at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries