Abstract FilePath Proposal

[Carter Schonwald]

So this goes back to a valid question:
What fraction of currently build able hackage breaks with such an Api
change, and how complex will fixing those breaks.


This should be evaluated.  And to what extent can the appropriate
migrations be mechanically assisted.
Would some of this breakage be mitigated by changing ++ to be monoid or
semigroup merge?

On Friday, July 3, 2015, John Lato <jwlato at gmail.com> wrote:

> In an ideal world, FilePath would be an abstract type. I think nearly
> everyone can agree on that.
>
> However, it seems every major ghc release includes some major breaking
> changes. I've spent a lot of time fixing the fallout from them, and this
> looks much more significant than any we've had in years.
>
> In particular, I'm quite scared that people attempted to gauge the fallout
> by building hackage, but it was too much work. Also consider that private
> codebases are likely to be impacted significantly (at least the ones I've
> seen will be).
>
> I think it's likely this will cause a major break in the ecosystem, with
> most packages only supporting old or new style FilePath.
>
> I guess my point is, I don't think this proposal should go ahead unless
> there's significant buy-in from the community (not merely silence or a
> small majority in favor). I'm not doing much Haskell these days so I'm
> pretty neutral on it.
>
> John L.
>
> On Tue, Jun 30, 2015, 2:25 AM Neil Mitchell <ndmitchell at gmail.com
> <javascript:_e(%7B%7D,'cvml','ndmitchell at gmail.com');>> wrote:
>
>> Hi David,
>>
>> > One tiny amendment to a comment(!) in the non-normative(!) code in
>> Phase 3:
>> >
>> > data WindowsFilePath = WFP ByteArray# -- UTF16 data
>> >
>> > If a Windows file path is valid UTF-16 then it is displayed as such in
>> the
>> > GUI, but if not it's still a legal file path. It really is just
>> wchar_t[]
>> > data.
>>
>> Thanks for bringing this up. It's tricky - I think in practice:
>>
>> toFilePath x = WPF (encodeStringAsUTF16 x)
>>
>> But the data in WPF will be treated as UCS2 (aka wchar_t) when passing
>> to the API calls, so it's really both. While on Windows NT it really
>> was UCS2, but Win 7 it's always treated as UTF16 in the GUI, so that
>> seems to be consistent with what people expect and ensures we don't
>> throw away information when converting to/from FilePath. Given it
>> seems you are quite knowledgeable in this area, please shout if that
>> seems misguided!
>>
>> To all the people who are worried about breakage, I can guarantee this
>> will cause breakage. It's a sad fact, and certainly the main negative
>> to this proposal. I was on the fence initially when hvr suggested this
>> change to me, but was convinced by performance and correctness.
>> Whether the Haskell community as a whole thinks that makes it worth it
>> is why it's a proposal. If anything, I'm concerned by the lack of
>> people saying -1, please don't break my code...
>>
>> Thanks, Neil
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> <javascript:_e(%7B%7D,'cvml','ghc-devs at haskell.org');>
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20150703/8aa79eda/attachment.html>