Abstract FilePath Proposal

[John Lato]

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> 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
> 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/20150704/3983e857/attachment.html>