Abstract FilePath Proposal

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
40 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Abstract FilePath Proposal

Erik Hesselink
I think this proposal is currently underspecified. For example, it's
not clear to me what the semantics of a FilePath are. I have the
feeling that `toFilePah` should return a Maybe, for example, but it's
hard to say without knowing what it's converting to, exactly.

I also worry about the immense breakage this will cause. This is not
just an issue of causing a lot of work for maintainers, but also of
lots of unmaintained libraries, printed code etc breaking. I feel that
there is not enough gain in this proposal relative to the amount of
breakage.

Has any thought been given to introduce new modules for this type, and
leave the old ones in place?

Erik

On Fri, Jun 26, 2015 at 6:08 PM, Herbert Valerio Riedel <[hidden email]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hello *,
>
> What?
> =====
>
> We (see From: & CC: headers) propose, plain and simple, to turn the
> currently defined type-synonym
>
>   type FilePath = String
>
> into an abstract/opaque data type instead.
>
> Why/How/When?
> =============
>
> For details (including motivation and a suggested transition scheme)
> please consult
>
>   https://ghc.haskell.org/trac/ghc/wiki/Proposal/AbstractFilePath
>
>
>
> Suggested discussion period: 4 weeks
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
>
> iQIcBAEBAgAGBQJVjXkZAAoJELo8uj/+IrV0WXUP/0romoKazwLbQpaMAKgCNZon
> BsY8Di44w6rkbdBXoky0xZooII8LJJyQfexH0BLRYEVLZFy0+LB8XzpPt8Ekg526
> YlY4x0qFm9oiJbJDMqHUnb6z6Lr2KxzBcV37drTPbltUA+HB49DUVkkPbvHimpL2
> 28SIyhAr4fN6fLpGcFAkv6Rcs0mkvnTp7vsC0HNyshmGi6qQ+C+eB4mklQzWOPcn
> koHZ2wtI8AJmyTdHKcXKAIFM0r+xl4MJ5445IvDjvIuGXZCzybXMw9Ss/4wSG3VN
> qSIJVEDGZXrBCc12fPxPEB0Bqx9MIVytjplXKIo8rFrk93h3at9t9kDM26z+9PZ5
> KYnEdjRKF4KL4j+3xqJDOEJT15GVRbGRRzb9A8xH0YIQ0S3Q3pt1PAfla1Hss75+
> NRQgfowZYryL9dfCkAj2XNfdQ+pUk25N3bNig11se+zjk2JO77QRM0u3GOYZ9+CU
> tSlwhtIMF32xnjgQyWE5yBBiEg3/Y+S+809tVaPseUEzkQJXMGq5TFxBrN6bj1Vm
> awr6QghThKjeoRwky5bmFn/gept/lbYN6VV5B6gNznGP5xgFrmvVtmjbQJBRMYCv
> aEUnrYqxkkbIddJjD5gl771/LWH4M2F1yBgJjfiZw2paEVAXKxEr327LsbOQaPdb
> HjIPRrJbVK9AABo4AZ/Y
> =lg0o
> -----END PGP SIGNATURE-----
> _______________________________________________
> ghc-devs mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Abstract FilePath Proposal

Michael Snoyman
Regarding underspecified: I think that's appropriate at this phase. The main proposal is: maybe FilePath an abstract type. It will take multiple GHC releases before we switch over fully, with plenty of time to hash out details of how the filepath package should work, and the opportunity to experiment with different wrappers around a core abstract type.

Having used an alternate FilePath type for a while (via system-filepath), I can say that it doesn't give the same benefit of just fixing the central FilePath type. Having to convert between types all over the place is tedious, defeats a lot of the performance benefits we're going for, and hurts type safety.

As someone who typically is very much opposed to breaking changes in core libraries: I think this one is well worth it.

On Mon, Jun 29, 2015 at 11:39 AM Erik Hesselink <[hidden email]> wrote:
I think this proposal is currently underspecified. For example, it's
not clear to me what the semantics of a FilePath are. I have the
feeling that `toFilePah` should return a Maybe, for example, but it's
hard to say without knowing what it's converting to, exactly.

I also worry about the immense breakage this will cause. This is not
just an issue of causing a lot of work for maintainers, but also of
lots of unmaintained libraries, printed code etc breaking. I feel that
there is not enough gain in this proposal relative to the amount of
breakage.

Has any thought been given to introduce new modules for this type, and
leave the old ones in place?

Erik

On Fri, Jun 26, 2015 at 6:08 PM, Herbert Valerio Riedel <[hidden email]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hello *,
>
> What?
> =====
>
> We (see From: & CC: headers) propose, plain and simple, to turn the
> currently defined type-synonym
>
>   type FilePath = String
>
> into an abstract/opaque data type instead.
>
> Why/How/When?
> =============
>
> For details (including motivation and a suggested transition scheme)
> please consult
>
>   https://ghc.haskell.org/trac/ghc/wiki/Proposal/AbstractFilePath
>
>
>
> Suggested discussion period: 4 weeks
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
>
> iQIcBAEBAgAGBQJVjXkZAAoJELo8uj/+IrV0WXUP/0romoKazwLbQpaMAKgCNZon
> BsY8Di44w6rkbdBXoky0xZooII8LJJyQfexH0BLRYEVLZFy0+LB8XzpPt8Ekg526
> YlY4x0qFm9oiJbJDMqHUnb6z6Lr2KxzBcV37drTPbltUA+HB49DUVkkPbvHimpL2
> 28SIyhAr4fN6fLpGcFAkv6Rcs0mkvnTp7vsC0HNyshmGi6qQ+C+eB4mklQzWOPcn
> koHZ2wtI8AJmyTdHKcXKAIFM0r+xl4MJ5445IvDjvIuGXZCzybXMw9Ss/4wSG3VN
> qSIJVEDGZXrBCc12fPxPEB0Bqx9MIVytjplXKIo8rFrk93h3at9t9kDM26z+9PZ5
> KYnEdjRKF4KL4j+3xqJDOEJT15GVRbGRRzb9A8xH0YIQ0S3Q3pt1PAfla1Hss75+
> NRQgfowZYryL9dfCkAj2XNfdQ+pUk25N3bNig11se+zjk2JO77QRM0u3GOYZ9+CU
> tSlwhtIMF32xnjgQyWE5yBBiEg3/Y+S+809tVaPseUEzkQJXMGq5TFxBrN6bj1Vm
> awr6QghThKjeoRwky5bmFn/gept/lbYN6VV5B6gNznGP5xgFrmvVtmjbQJBRMYCv
> aEUnrYqxkkbIddJjD5gl771/LWH4M2F1yBgJjfiZw2paEVAXKxEr327LsbOQaPdb
> HjIPRrJbVK9AABo4AZ/Y
> =lg0o
> -----END PGP SIGNATURE-----
> _______________________________________________
> ghc-devs mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Abstract FilePath Proposal

Erik Hesselink
On Mon, Jun 29, 2015 at 10:46 AM, Michael Snoyman <[hidden email]> wrote:
> Regarding underspecified: I think that's appropriate at this phase. The main
> proposal is: maybe FilePath an abstract type. It will take multiple GHC
> releases before we switch over fully, with plenty of time to hash out
> details of how the filepath package should work, and the opportunity to
> experiment with different wrappers around a core abstract type.

But changing the semantics of an established newtype is very tricky
business, since the resulting breakage won't be indicated by the
types!

> Having used an alternate FilePath type for a while (via system-filepath), I
> can say that it doesn't give the same benefit of just fixing the central
> FilePath type. Having to convert between types all over the place is
> tedious, defeats a lot of the performance benefits we're going for, and
> hurts type safety.

Why would you have to convert 'all over the place'? If the alternative
library also provides the basic IO functions, the only places you'd
have to convert are interfaces with other libraries, and things from
e.g. config file, both of which don't happen a lot.

> As someone who typically is very much opposed to breaking changes in core
> libraries: I think this one is well worth it.

Do you have any insight in the amount of breakage this will cause? I
have a gut feeling that it's a lot more than any of the previous
changes we've had, and those have already caused a lot of grumbling.
But the only way to be sure is to run the builds on hackage (or
stackage, but that's a smaller sample size).

Erik

> On Mon, Jun 29, 2015 at 11:39 AM Erik Hesselink <[hidden email]> wrote:
>>
>> I think this proposal is currently underspecified. For example, it's
>> not clear to me what the semantics of a FilePath are. I have the
>> feeling that `toFilePah` should return a Maybe, for example, but it's
>> hard to say without knowing what it's converting to, exactly.
>>
>> I also worry about the immense breakage this will cause. This is not
>> just an issue of causing a lot of work for maintainers, but also of
>> lots of unmaintained libraries, printed code etc breaking. I feel that
>> there is not enough gain in this proposal relative to the amount of
>> breakage.
>>
>> Has any thought been given to introduce new modules for this type, and
>> leave the old ones in place?
>>
>> Erik
>>
>> On Fri, Jun 26, 2015 at 6:08 PM, Herbert Valerio Riedel <[hidden email]>
>> wrote:
>> > -----BEGIN PGP SIGNED MESSAGE-----
>> > Hash: SHA1
>> >
>> > Hello *,
>> >
>> > What?
>> > =====
>> >
>> > We (see From: & CC: headers) propose, plain and simple, to turn the
>> > currently defined type-synonym
>> >
>> >   type FilePath = String
>> >
>> > into an abstract/opaque data type instead.
>> >
>> > Why/How/When?
>> > =============
>> >
>> > For details (including motivation and a suggested transition scheme)
>> > please consult
>> >
>> >   https://ghc.haskell.org/trac/ghc/wiki/Proposal/AbstractFilePath
>> >
>> >
>> >
>> > Suggested discussion period: 4 weeks
>> > -----BEGIN PGP SIGNATURE-----
>> > Version: GnuPG v1
>> >
>> > iQIcBAEBAgAGBQJVjXkZAAoJELo8uj/+IrV0WXUP/0romoKazwLbQpaMAKgCNZon
>> > BsY8Di44w6rkbdBXoky0xZooII8LJJyQfexH0BLRYEVLZFy0+LB8XzpPt8Ekg526
>> > YlY4x0qFm9oiJbJDMqHUnb6z6Lr2KxzBcV37drTPbltUA+HB49DUVkkPbvHimpL2
>> > 28SIyhAr4fN6fLpGcFAkv6Rcs0mkvnTp7vsC0HNyshmGi6qQ+C+eB4mklQzWOPcn
>> > koHZ2wtI8AJmyTdHKcXKAIFM0r+xl4MJ5445IvDjvIuGXZCzybXMw9Ss/4wSG3VN
>> > qSIJVEDGZXrBCc12fPxPEB0Bqx9MIVytjplXKIo8rFrk93h3at9t9kDM26z+9PZ5
>> > KYnEdjRKF4KL4j+3xqJDOEJT15GVRbGRRzb9A8xH0YIQ0S3Q3pt1PAfla1Hss75+
>> > NRQgfowZYryL9dfCkAj2XNfdQ+pUk25N3bNig11se+zjk2JO77QRM0u3GOYZ9+CU
>> > tSlwhtIMF32xnjgQyWE5yBBiEg3/Y+S+809tVaPseUEzkQJXMGq5TFxBrN6bj1Vm
>> > awr6QghThKjeoRwky5bmFn/gept/lbYN6VV5B6gNznGP5xgFrmvVtmjbQJBRMYCv
>> > aEUnrYqxkkbIddJjD5gl771/LWH4M2F1yBgJjfiZw2paEVAXKxEr327LsbOQaPdb
>> > HjIPRrJbVK9AABo4AZ/Y
>> > =lg0o
>> > -----END PGP SIGNATURE-----
>> > _______________________________________________
>> > ghc-devs mailing list
>> > [hidden email]
>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>> _______________________________________________
>> ghc-devs mailing list
>> [hidden email]
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Abstract FilePath Proposal

Michael Snoyman


On Mon, Jun 29, 2015 at 12:07 PM Erik Hesselink <[hidden email]> wrote:
On Mon, Jun 29, 2015 at 10:46 AM, Michael Snoyman <[hidden email]> wrote:
> Regarding underspecified: I think that's appropriate at this phase. The main
> proposal is: maybe FilePath an abstract type. It will take multiple GHC
> releases before we switch over fully, with plenty of time to hash out
> details of how the filepath package should work, and the opportunity to
> experiment with different wrappers around a core abstract type.

But changing the semantics of an established newtype is very tricky
business, since the resulting breakage won't be indicated by the
types!


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.
 
> Having used an alternate FilePath type for a while (via system-filepath), I
> can say that it doesn't give the same benefit of just fixing the central
> FilePath type. Having to convert between types all over the place is
> tedious, defeats a lot of the performance benefits we're going for, and
> hurts type safety.

Why would you have to convert 'all over the place'? If the alternative
library also provides the basic IO functions, the only places you'd
have to convert are interfaces with other libraries, and things from
e.g. config file, both of which don't happen a lot.


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.
 
> As someone who typically is very much opposed to breaking changes in core
> libraries: I think this one is well worth it.

Do you have any insight in the amount of breakage this will cause? I
have a gut feeling that it's a lot more than any of the previous
changes we've had, and those have already caused a lot of grumbling.
But the only way to be sure is to run the builds on hackage (or
stackage, but that's a smaller sample size).


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.
 
Erik

> On Mon, Jun 29, 2015 at 11:39 AM Erik Hesselink <[hidden email]> wrote:
>>
>> I think this proposal is currently underspecified. For example, it's
>> not clear to me what the semantics of a FilePath are. I have the
>> feeling that `toFilePah` should return a Maybe, for example, but it's
>> hard to say without knowing what it's converting to, exactly.
>>
>> I also worry about the immense breakage this will cause. This is not
>> just an issue of causing a lot of work for maintainers, but also of
>> lots of unmaintained libraries, printed code etc breaking. I feel that
>> there is not enough gain in this proposal relative to the amount of
>> breakage.
>>
>> Has any thought been given to introduce new modules for this type, and
>> leave the old ones in place?
>>
>> Erik
>>
>> On Fri, Jun 26, 2015 at 6:08 PM, Herbert Valerio Riedel <[hidden email]>
>> wrote:
>> > -----BEGIN PGP SIGNED MESSAGE-----
>> > Hash: SHA1
>> >
>> > Hello *,
>> >
>> > What?
>> > =====
>> >
>> > We (see From: & CC: headers) propose, plain and simple, to turn the
>> > currently defined type-synonym
>> >
>> >   type FilePath = String
>> >
>> > into an abstract/opaque data type instead.
>> >
>> > Why/How/When?
>> > =============
>> >
>> > For details (including motivation and a suggested transition scheme)
>> > please consult
>> >
>> >   https://ghc.haskell.org/trac/ghc/wiki/Proposal/AbstractFilePath
>> >
>> >
>> >
>> > Suggested discussion period: 4 weeks
>> > -----BEGIN PGP SIGNATURE-----
>> > Version: GnuPG v1
>> >
>> > iQIcBAEBAgAGBQJVjXkZAAoJELo8uj/+IrV0WXUP/0romoKazwLbQpaMAKgCNZon
>> > BsY8Di44w6rkbdBXoky0xZooII8LJJyQfexH0BLRYEVLZFy0+LB8XzpPt8Ekg526
>> > YlY4x0qFm9oiJbJDMqHUnb6z6Lr2KxzBcV37drTPbltUA+HB49DUVkkPbvHimpL2
>> > 28SIyhAr4fN6fLpGcFAkv6Rcs0mkvnTp7vsC0HNyshmGi6qQ+C+eB4mklQzWOPcn
>> > koHZ2wtI8AJmyTdHKcXKAIFM0r+xl4MJ5445IvDjvIuGXZCzybXMw9Ss/4wSG3VN
>> > qSIJVEDGZXrBCc12fPxPEB0Bqx9MIVytjplXKIo8rFrk93h3at9t9kDM26z+9PZ5
>> > KYnEdjRKF4KL4j+3xqJDOEJT15GVRbGRRzb9A8xH0YIQ0S3Q3pt1PAfla1Hss75+
>> > NRQgfowZYryL9dfCkAj2XNfdQ+pUk25N3bNig11se+zjk2JO77QRM0u3GOYZ9+CU
>> > tSlwhtIMF32xnjgQyWE5yBBiEg3/Y+S+809tVaPseUEzkQJXMGq5TFxBrN6bj1Vm
>> > awr6QghThKjeoRwky5bmFn/gept/lbYN6VV5B6gNznGP5xgFrmvVtmjbQJBRMYCv
>> > aEUnrYqxkkbIddJjD5gl771/LWH4M2F1yBgJjfiZw2paEVAXKxEr327LsbOQaPdb
>> > HjIPRrJbVK9AABo4AZ/Y
>> > =lg0o
>> > -----END PGP SIGNATURE-----
>> > _______________________________________________
>> > ghc-devs mailing list
>> > [hidden email]
>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>> _______________________________________________
>> ghc-devs mailing list
>> [hidden email]
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Abstract FilePath Proposal

David Turner-2
In reply to this post by Herbert Valerio Riedel
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:

data WindowsFilePath = WFP ByteArray# -- wchar_t[] data as passed to syscalls

This seems to be the source of some confusion.

Cheers,

David 


On 26 June 2015 at 17:08, Herbert Valerio Riedel <[hidden email]> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello *,

What?
=====

We (see From: & CC: headers) propose, plain and simple, to turn the
currently defined type-synonym

  type FilePath = String

into an abstract/opaque data type instead.

Why/How/When?
=============

For details (including motivation and a suggested transition scheme)
please consult

  https://ghc.haskell.org/trac/ghc/wiki/Proposal/AbstractFilePath



Suggested discussion period: 4 weeks
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJVjXkZAAoJELo8uj/+IrV0WXUP/0romoKazwLbQpaMAKgCNZon
BsY8Di44w6rkbdBXoky0xZooII8LJJyQfexH0BLRYEVLZFy0+LB8XzpPt8Ekg526
YlY4x0qFm9oiJbJDMqHUnb6z6Lr2KxzBcV37drTPbltUA+HB49DUVkkPbvHimpL2
28SIyhAr4fN6fLpGcFAkv6Rcs0mkvnTp7vsC0HNyshmGi6qQ+C+eB4mklQzWOPcn
koHZ2wtI8AJmyTdHKcXKAIFM0r+xl4MJ5445IvDjvIuGXZCzybXMw9Ss/4wSG3VN
qSIJVEDGZXrBCc12fPxPEB0Bqx9MIVytjplXKIo8rFrk93h3at9t9kDM26z+9PZ5
KYnEdjRKF4KL4j+3xqJDOEJT15GVRbGRRzb9A8xH0YIQ0S3Q3pt1PAfla1Hss75+
NRQgfowZYryL9dfCkAj2XNfdQ+pUk25N3bNig11se+zjk2JO77QRM0u3GOYZ9+CU
tSlwhtIMF32xnjgQyWE5yBBiEg3/Y+S+809tVaPseUEzkQJXMGq5TFxBrN6bj1Vm
awr6QghThKjeoRwky5bmFn/gept/lbYN6VV5B6gNznGP5xgFrmvVtmjbQJBRMYCv
aEUnrYqxkkbIddJjD5gl771/LWH4M2F1yBgJjfiZw2paEVAXKxEr327LsbOQaPdb
HjIPRrJbVK9AABo4AZ/Y
=lg0o
-----END PGP SIGNATURE-----
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Abstract FilePath Proposal

Aloïs Cochard
+1 for the first two phase of the original proposal. I always wished it was not a type alias.

No strong opinion of phase 3, I have propabaly never run into sophisticated enough issues to fully get the picture... but I doubt we'll be able to craft an ideal cross-platform API, I like what is in spirit in the original proposal.

On 29 June 2015 at 11:27, David Turner <[hidden email]> wrote:
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:

data WindowsFilePath = WFP ByteArray# -- wchar_t[] data as passed to syscalls

This seems to be the source of some confusion.

Cheers,

David 


On 26 June 2015 at 17:08, Herbert Valerio Riedel <[hidden email]> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello *,

What?
=====

We (see From: & CC: headers) propose, plain and simple, to turn the
currently defined type-synonym

  type FilePath = String

into an abstract/opaque data type instead.

Why/How/When?
=============

For details (including motivation and a suggested transition scheme)
please consult

  https://ghc.haskell.org/trac/ghc/wiki/Proposal/AbstractFilePath



Suggested discussion period: 4 weeks
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJVjXkZAAoJELo8uj/+IrV0WXUP/0romoKazwLbQpaMAKgCNZon
BsY8Di44w6rkbdBXoky0xZooII8LJJyQfexH0BLRYEVLZFy0+LB8XzpPt8Ekg526
YlY4x0qFm9oiJbJDMqHUnb6z6Lr2KxzBcV37drTPbltUA+HB49DUVkkPbvHimpL2
28SIyhAr4fN6fLpGcFAkv6Rcs0mkvnTp7vsC0HNyshmGi6qQ+C+eB4mklQzWOPcn
koHZ2wtI8AJmyTdHKcXKAIFM0r+xl4MJ5445IvDjvIuGXZCzybXMw9Ss/4wSG3VN
qSIJVEDGZXrBCc12fPxPEB0Bqx9MIVytjplXKIo8rFrk93h3at9t9kDM26z+9PZ5
KYnEdjRKF4KL4j+3xqJDOEJT15GVRbGRRzb9A8xH0YIQ0S3Q3pt1PAfla1Hss75+
NRQgfowZYryL9dfCkAj2XNfdQ+pUk25N3bNig11se+zjk2JO77QRM0u3GOYZ9+CU
tSlwhtIMF32xnjgQyWE5yBBiEg3/Y+S+809tVaPseUEzkQJXMGq5TFxBrN6bj1Vm
awr6QghThKjeoRwky5bmFn/gept/lbYN6VV5B6gNznGP5xgFrmvVtmjbQJBRMYCv
aEUnrYqxkkbIddJjD5gl771/LWH4M2F1yBgJjfiZw2paEVAXKxEr327LsbOQaPdb
HjIPRrJbVK9AABo4AZ/Y
=lg0o
-----END PGP SIGNATURE-----
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs




--

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Abstract FilePath Proposal

Neil Mitchell
In reply to this post by David Turner-2
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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Abstract FilePath Proposal

Erik Hesselink
On Tue, Jun 30, 2015 at 11:25 AM, Neil Mitchell <[hidden email]> wrote:
> 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...

I'm not convinced by the performance argument. Most people don't need
performance from the small amount of FilePath usage they have. Those
who do can switch to a different package. Now correctness would be a
good argument, but this proposal doesn't really add that much in that
respect, it seems.

I'm still on the fence, but leaning towards -1, but I'm not saying
please don't break my code. My code will be fine, I'm around to fix
it. I'm more worried about other people's code (that I might rely on),
maintainers that have left, or aren't that responsive, newcomers
reading old tutorials, people getting angry about needing more
CPP/fixing more code on new GHC releases, etc. We're still breaking
code on every new GHC release, and it seems the amount of breakage is
only increasing.

Erik
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Abstract FilePath Proposal

John Lato-2
In reply to this post by Neil Mitchell

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

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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 <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;ndmitchell@gmail.com&#39;);" target="_blank">ndmitchell@...> 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
<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;ghc-devs@haskell.org&#39;);" target="_blank">ghc-devs@...
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Abstract FilePath Proposal

Sven Panne-2
2015-07-04 4:28 GMT+02:00 Carter Schonwald <[hidden email]>:
[...] What fraction of currently build able hackage breaks with such an Api change, and how complex will fixing those breaks.  [...]

I think it is highly irrelevant how complex fixing the breakage is, it will probably almost always be trivial, but that's not the point: Think e.g. about a package which didn't really need any update for a few years, its maintainer is inactive (nothing to recently, so that's OK), and which is a transitive dependency of a number of other packages. This will effectively mean lots of broken packages for weeks or even longer. Fixing breakage from the AMP or FTP proposals was trivial, too, but nevertheless a bit painful. 

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? 

To me the fundamental question which should be answered before any detail question is: Should we go on and continuously break minor things (i.e. basically give up any stability guarantees) or should we collect a bunch of changes first (leaving vital things untouched for that time) and release all those changes together, in longer intervals? That's IMHO a tough question which we somehow avoided to answer up to now. I would like to see a broader discussion like this first, both approaches have their pros and cons, and whatever we do, there should be some kind of consensus behind it.

Cheers,
   S.

P.S.: Just for the record: I'm leaning towards the "lots-of-changes-after-a-longer-time" approach, otherwise I see a flood of #ifdefs and tons of failing builds coming our way... :-P

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Abstract FilePath Proposal

Brandon Allbery
On Sat, Jul 4, 2015 at 3:26 PM, Sven Panne <[hidden email]> wrote:
To me the fundamental question which should be answered before any detail question is: Should we go on and continuously break minor things (i.e. basically give up any stability guarantees) or should we collect a bunch of changes first (leaving vital things untouched for that time) and release all those changes together, in longer intervals? That's IMHO a tough question which we somehow avoided to answer up to now. I would like to see a broader discussion like this first, both approaches have their pros and cons, and whatever we do, there should be some kind of consensus behind it.

I recall suggesting something along the lines of stable vs. research ghc releases a few months back. This seems like it would fit in fairly well; the problem is getting buy-in from certain parts of the ecosystem that seem to prefer to build production-oriented packages from research/"unstable" releases.

--
brandon s allbery kf8nh                               sine nomine associates
[hidden email]                                  [hidden email]
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Abstract FilePath Proposal

Sven Panne-2
In reply to this post by Sven Panne-2
2015-07-04 22:48 GMT+02:00 <[hidden email]>:
I'd argue that Haskell and GHC's history clearly shows we've answered that question and that overalll we value frequent small breaking changes over giant change roadblocks like Perl's or Python's. [...]

I'm not sure that "value" is the right word. My impression is more that this somehow happened accidentally and was not the result of careful planning or broad consensus. And even if in the past this might have been the right thing, I consider today's state of affairs as something totally different: In the past it was only GHC, small parts of the language or a handful of packages (or even just a few modules, in the pre-package times). Today every change resonates through thousands of packages on Hackage and elsewhere. IMHO some approach similar to e.g. C++03 => C++11 => C++14 makes more sense in world like this than a constantly fluctuating base, but others might see this differently. My fear is that this will inevitably lead to the necessity of having an autoconf-like feature detection machinery to compile a package, and looking at a few packages, we are already halfway there. :-/

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Abstract FilePath Proposal

Bardur Arantsson-2
In reply to this post by Brandon Allbery
On 07/04/2015 09:38 PM, Brandon Allbery wrote:

> On Sat, Jul 4, 2015 at 3:26 PM, Sven Panne <[hidden email]> wrote:
>
>> To me the fundamental question which should be answered before any detail
>> question is: Should we go on and continuously break minor things (i.e.
>> basically give up any stability guarantees) or should we collect a bunch of
>> changes first (leaving vital things untouched for that time) and release
>> all those changes together, in longer intervals? That's IMHO a tough
>> question which we somehow avoided to answer up to now. I would like to see
>> a broader discussion like this first, both approaches have their pros and
>> cons, and whatever we do, there should be some kind of consensus behind it.
>
>
> I recall suggesting something along the lines of stable vs. research ghc
> releases a few months back. This seems like it would fit in fairly well;
> the problem is getting buy-in from certain parts of the ecosystem that seem
> to prefer to build production-oriented packages from research/"unstable"
> releases.
>

But isn't that effectively just the same as saying: "In our organization
we'll be staying with GHC 7.8.x until GHC 7.12.x comes out"? (Or
similar, I'm sure you get the point.)

Yes, the rest of the ecosystem may move along and use the latest new
shiny, but then you can always use the packages that worked with GHC
7.8.x thanks to version ranges.

Am I missing something?

Regards,

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Abstract FilePath Proposal

Brandon Allbery
On Sat, Jul 4, 2015 at 6:17 PM, Bardur Arantsson <[hidden email]> wrote:
Yes, the rest of the ecosystem may move along and use the latest new
shiny, but then you can always use the packages that worked with GHC
7.8.x thanks to version ranges.

Am I missing something?

Updates needed to fix e.g. security issues, which otherwise might not be backported if others are staying close to current. This is why Stackage has both LTS and Nightly; LTS only works if there's a *commitment* to it, at the level of the community for a community resource or at the level of the provider for something like ghc or Stackage.

Note that GHC HQ's response was that they have had problems finding people to keep multiple versions active at the same time; it's a significant job given that backporting (say) a fix to a type system issue allowing unexpectedly unsafe code (say, https://ghc.haskell.org/trac/ghc/ticket/9858) can mean a complete redesign of the patch, if the one in HEAD relies on other changes that can't be sensibly backported.

--
brandon s allbery kf8nh                               sine nomine associates
[hidden email]                                  [hidden email]
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Abstract FilePath Proposal

M Farkas-Dyck
In reply to this post by Sven Panne-2
On 04/07/2015 at 21:26:31 +0200, Sven Panne wrote:
> To me the fundamental question which should be answered before any detail
> question is: Should we go on and continuously break minor things (i.e.
> basically give up any stability guarantees) or should we collect a bunch of
> changes first (leaving vital things untouched for that time) and release
> all those changes together, in longer intervals? That's IMHO a tough
> question which we somehow avoided to answer up to now. I would like to see
> a broader discussion like this first, both approaches have their pros and
> cons, and whatever we do, there should be some kind of consensus behind it.

Potentially we ought to await Backpack [0], which should make such transitions easier.

[0] http://plv.mpi-sws.org/backpack/
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Abstract FilePath Proposal

Bardur Arantsson-2
In reply to this post by Brandon Allbery
On 07/05/2015 12:27 AM, Brandon Allbery wrote:

> On Sat, Jul 4, 2015 at 6:17 PM, Bardur Arantsson <[hidden email]>
> wrote:
>
>> Yes, the rest of the ecosystem may move along and use the latest new
>> shiny, but then you can always use the packages that worked with GHC
>> 7.8.x thanks to version ranges.
>>
>> Am I missing something?
>>
>
> Updates needed to fix e.g. security issues, which otherwise might not be
> backported if others are staying close to current. This is why Stackage has
> both LTS and Nightly; LTS only works if there's a *commitment* to it, at
> the level of the community for a community resource or at the level of the
> provider for something like ghc or Stackage.
>

How often have security issues with GHC (or the base libraries) itself
been a problem? (In practice, I mean.)

In my hypothetical scenario, there's nothing to prevent a release of

   GHC 7.8.(x+1)

while GHC 7.12. is the new thing. Nor does anything prevent library
releases of

     my-library-1.2.x (security patch)

while

     my-library-1.6.x

is the hot new thing.

> Note that GHC HQ's response was that they have had problems finding people
> to keep multiple versions active at the same time; it's a significant job
> given that backporting (say) a fix to a type system issue allowing
> unexpectedly unsafe code (say, https://ghc.haskell.org/trac/ghc/ticket/9858)
> can mean a complete redesign of the patch, if the one in HEAD relies on
> other changes that can't be sensibly backported.
>

Yes, there's a man-power problem... but that isn't going to be solved
unless some people/companies step up to the plate. Preferably the people
who are actually using/relying on those old versions. This is no
different from e.g. RHEL/Ubuntu LTS/Debian in the Linux world. (Well,
except RHEL actually has a revenue stream that means that they can and
do support old versions of various things.)

Regards,

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Abstract FilePath Proposal

Brandon Allbery
On Sun, Jul 5, 2015 at 2:25 PM, Bardur Arantsson <[hidden email]> wrote:
How often have security issues with GHC (or the base libraries) itself
been a problem? (In practice, I mean.)

Not that often, but consider one real example: aeson was found to have a DDoS bug which was fixed by making it depend on a package which IIRC needed a newer base, so the fix couldn't be backported to versions of aeson compatible with older base. The necessary fix for those would have been substantially more complicated.

(There are other examples, but the primary one that actually involves something shipped with ghc is never going to be fixed until it destroys someone's system, and I bet even then we'll get another load of HOMG MUST NEVER CHANGE API ONLY DOCUMENT AS BAD from the maintainer. I'm still waiting for one of the Linux distributions to notice and CVE it.)

--
brandon s allbery kf8nh                               sine nomine associates
[hidden email]                                  [hidden email]
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Abstract FilePath Proposal

Bardur Arantsson-2
On 07/05/2015 08:40 PM, Brandon Allbery wrote:

> On Sun, Jul 5, 2015 at 2:25 PM, Bardur Arantsson <[hidden email]>
> wrote:
>
>> How often have security issues with GHC (or the base libraries) itself
>> been a problem? (In practice, I mean.)
>>
>
> Not that often, but consider one real example: aeson was found to have a
> DDoS bug which was fixed by making it depend on a package which IIRC needed
> a newer base, so the fix couldn't be backported to versions of aeson
> compatible with older base. The necessary fix for those would have been
> substantially more complicated.
>
> (There are other examples, but the primary one that actually involves
> something shipped with ghc is never going to be fixed until it destroys
> someone's system, and I bet even then we'll get another load of HOMG MUST
> NEVER CHANGE API ONLY DOCUMENT AS BAD from the maintainer. I'm still
> waiting for one of the Linux distributions to notice and CVE it.)
>

Oh, yeah, that's a valid point... but is this something that should
drive design?

Further, I don't think the aeson DDoS problem was predicated on an
old/obsolete "base" library? Maybe I'm wrong about that, and I'm sure
y'all will be happy to point out where and why. :)

Regards,

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Abstract FilePath Proposal

Brandon Allbery
On Sun, Jul 5, 2015 at 3:27 PM, Bardur Arantsson <[hidden email]> wrote:
Further, I don't think the aeson DDoS problem was predicated on an
old/obsolete "base" library? Maybe I'm wrong about that, and I'm sure
y'all will be happy to point out where and why. :)

I may be misremembering, but I thought one of the complaints about aeson adding scientific to its dependencies (to fix the DDoS) was that it required a newer ghc?

--
brandon s allbery kf8nh                               sine nomine associates
[hidden email]                                  [hidden email]
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
12