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