<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Mon, Jun 29, 2015 at 12:07 PM Erik Hesselink <<a href="mailto:hesselink@gmail.com">hesselink@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Mon, Jun 29, 2015 at 10:46 AM, Michael Snoyman <<a href="mailto:michael@snoyman.com" target="_blank">michael@snoyman.com</a>> wrote:<br>
> Regarding underspecified: I think that's appropriate at this phase. The main<br>
> proposal is: maybe FilePath an abstract type. It will take multiple GHC<br>
> releases before we switch over fully, with plenty of time to hash out<br>
> details of how the filepath package should work, and the opportunity to<br>
> experiment with different wrappers around a core abstract type.<br>
<br>
But changing the semantics of an established newtype is very tricky<br>
business, since the resulting breakage won't be indicated by the<br>
types!<br>
<br></blockquote><div><br></div><div>My suggestion isn't to roll out one breaking change and then another silent semantics change later. Rather, my point is: getting FilePath to be an abstract type is the meat of the proposal, and what we need to agree on. Working out the exact semantics of how the filepath package interacts with that is important, but not urgent. Let's get to an agreement that an abstract type is an improvement, and then we can figure out exactly how it should behave. After all, we'll have about 2 years to figure that out.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> Having used an alternate FilePath type for a while (via system-filepath), I<br>
> can say that it doesn't give the same benefit of just fixing the central<br>
> FilePath type. Having to convert between types all over the place is<br>
> tedious, defeats a lot of the performance benefits we're going for, and<br>
> hurts type safety.<br>
<br>
Why would you have to convert 'all over the place'? If the alternative<br>
library also provides the basic IO functions, the only places you'd<br>
have to convert are interfaces with other libraries, and things from<br>
e.g. config file, both of which don't happen a lot.<br>
<br></blockquote><div><br></div><div>By having two different types, we know that not everyone will convert over. In fact, the very argument for having two types is so that not everyone will need to convert. Especially if Prelude continues to export the current `type FilePath = [Char]`, it will be difficult to get all libraries to use the new type.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> As someone who typically is very much opposed to breaking changes in core<br>
> libraries: I think this one is well worth it.<br>
<br>
Do you have any insight in the amount of breakage this will cause? I<br>
have a gut feeling that it's a lot more than any of the previous<br>
changes we've had, and those have already caused a lot of grumbling.<br>
But the only way to be sure is to run the builds on hackage (or<br>
stackage, but that's a smaller sample size).<br>
<br></blockquote><div><br></div><div>I agree, this is going to be a big one. It does not lend itself to elegant migrations like FTP did, for instance. But the scope of the current problem is also large, which is why I believe this breakage is warranted. Doing it gradually with a deprecation plan will hopefully make it possible for us to make it as easy as possible.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Erik<br>
<br>
> On Mon, Jun 29, 2015 at 11:39 AM Erik Hesselink <<a href="mailto:hesselink@gmail.com" target="_blank">hesselink@gmail.com</a>> wrote:<br>
>><br>
>> I think this proposal is currently underspecified. For example, it's<br>
>> not clear to me what the semantics of a FilePath are. I have the<br>
>> feeling that `toFilePah` should return a Maybe, for example, but it's<br>
>> hard to say without knowing what it's converting to, exactly.<br>
>><br>
>> I also worry about the immense breakage this will cause. This is not<br>
>> just an issue of causing a lot of work for maintainers, but also of<br>
>> lots of unmaintained libraries, printed code etc breaking. I feel that<br>
>> there is not enough gain in this proposal relative to the amount of<br>
>> breakage.<br>
>><br>
>> Has any thought been given to introduce new modules for this type, and<br>
>> leave the old ones in place?<br>
>><br>
>> Erik<br>
>><br>
>> On Fri, Jun 26, 2015 at 6:08 PM, Herbert Valerio Riedel <<a href="mailto:hvr@gnu.org" target="_blank">hvr@gnu.org</a>><br>
>> wrote:<br>
>> > -----BEGIN PGP SIGNED MESSAGE-----<br>
>> > Hash: SHA1<br>
>> ><br>
>> > Hello *,<br>
>> ><br>
>> > What?<br>
>> > =====<br>
>> ><br>
>> > We (see From: & CC: headers) propose, plain and simple, to turn the<br>
>> > currently defined type-synonym<br>
>> ><br>
>> >   type FilePath = String<br>
>> ><br>
>> > into an abstract/opaque data type instead.<br>
>> ><br>
>> > Why/How/When?<br>
>> > =============<br>
>> ><br>
>> > For details (including motivation and a suggested transition scheme)<br>
>> > please consult<br>
>> ><br>
>> >   <a href="https://ghc.haskell.org/trac/ghc/wiki/Proposal/AbstractFilePath" rel="noreferrer" target="_blank">https://ghc.haskell.org/trac/ghc/wiki/Proposal/AbstractFilePath</a><br>
>> ><br>
>> ><br>
>> ><br>
>> > Suggested discussion period: 4 weeks<br>
>> > -----BEGIN PGP SIGNATURE-----<br>
>> > Version: GnuPG v1<br>
>> ><br>
>> > iQIcBAEBAgAGBQJVjXkZAAoJELo8uj/+IrV0WXUP/0romoKazwLbQpaMAKgCNZon<br>
>> > BsY8Di44w6rkbdBXoky0xZooII8LJJyQfexH0BLRYEVLZFy0+LB8XzpPt8Ekg526<br>
>> > YlY4x0qFm9oiJbJDMqHUnb6z6Lr2KxzBcV37drTPbltUA+HB49DUVkkPbvHimpL2<br>
>> > 28SIyhAr4fN6fLpGcFAkv6Rcs0mkvnTp7vsC0HNyshmGi6qQ+C+eB4mklQzWOPcn<br>
>> > koHZ2wtI8AJmyTdHKcXKAIFM0r+xl4MJ5445IvDjvIuGXZCzybXMw9Ss/4wSG3VN<br>
>> > qSIJVEDGZXrBCc12fPxPEB0Bqx9MIVytjplXKIo8rFrk93h3at9t9kDM26z+9PZ5<br>
>> > KYnEdjRKF4KL4j+3xqJDOEJT15GVRbGRRzb9A8xH0YIQ0S3Q3pt1PAfla1Hss75+<br>
>> > NRQgfowZYryL9dfCkAj2XNfdQ+pUk25N3bNig11se+zjk2JO77QRM0u3GOYZ9+CU<br>
>> > tSlwhtIMF32xnjgQyWE5yBBiEg3/Y+S+809tVaPseUEzkQJXMGq5TFxBrN6bj1Vm<br>
>> > awr6QghThKjeoRwky5bmFn/gept/lbYN6VV5B6gNznGP5xgFrmvVtmjbQJBRMYCv<br>
>> > aEUnrYqxkkbIddJjD5gl771/LWH4M2F1yBgJjfiZw2paEVAXKxEr327LsbOQaPdb<br>
>> > HjIPRrJbVK9AABo4AZ/Y<br>
>> > =lg0o<br>
>> > -----END PGP SIGNATURE-----<br>
>> > _______________________________________________<br>
>> > ghc-devs mailing list<br>
>> > <a href="mailto: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>
>> _______________________________________________<br>
>> ghc-devs mailing list<br>
>> <a href="mailto: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></div>