So this goes back to a valid question: <div>What fraction of currently build able hackage breaks with such an Api change, and how complex will fixing those breaks. </div><div><br></div><div><br></div><div>This should be evaluated.  And to what extent can the appropriate migrations be mechanically assisted. </div><div>Would some of this breakage be mitigated by changing ++ to be monoid or semigroup merge? <span></span><br><br>On Friday, July 3, 2015, John Lato <<a href="mailto:jwlato@gmail.com">jwlato@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">In an ideal world, FilePath would be an abstract type. I think nearly everyone can agree on that.</p>
<p dir="ltr">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.</p>
<p dir="ltr">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).</p>
<p dir="ltr">I think it's likely this will cause a major break in the ecosystem, with most packages only supporting old or new style FilePath.</p>
<p dir="ltr">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.</p>
<p dir="ltr">John L.</p>

<br><div class="gmail_quote"><div dir="ltr">On Tue, Jun 30, 2015, 2:25 AM Neil Mitchell <<a href="javascript:_e(%7B%7D,'cvml','ndmitchell@gmail.com');" target="_blank">ndmitchell@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi David,<br>
<br>
> One tiny amendment to a comment(!) in the non-normative(!) code in Phase 3:<br>
><br>
> data WindowsFilePath = WFP ByteArray# -- UTF16 data<br>
><br>
> If a Windows file path is valid UTF-16 then it is displayed as such in the<br>
> GUI, but if not it's still a legal file path. It really is just wchar_t[]<br>
> data.<br>
<br>
Thanks for bringing this up. It's tricky - I think in practice:<br>
<br>
toFilePath x = WPF (encodeStringAsUTF16 x)<br>
<br>
But the data in WPF will be treated as UCS2 (aka wchar_t) when passing<br>
to the API calls, so it's really both. While on Windows NT it really<br>
was UCS2, but Win 7 it's always treated as UTF16 in the GUI, so that<br>
seems to be consistent with what people expect and ensures we don't<br>
throw away information when converting to/from FilePath. Given it<br>
seems you are quite knowledgeable in this area, please shout if that<br>
seems misguided!<br>
<br>
To all the people who are worried about breakage, I can guarantee this<br>
will cause breakage. It's a sad fact, and certainly the main negative<br>
to this proposal. I was on the fence initially when hvr suggested this<br>
change to me, but was convinced by performance and correctness.<br>
Whether the Haskell community as a whole thinks that makes it worth it<br>
is why it's a proposal. If anything, I'm concerned by the lack of<br>
people saying -1, please don't break my code...<br>
<br>
Thanks, Neil<br>
_______________________________________________<br>
ghc-devs mailing list<br>
<a href="javascript:_e(%7B%7D,'cvml','ghc-devs@haskell.org');" target="_blank">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
</blockquote></div>
</blockquote></div>