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 <hesselink at gmail.com> 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 <hvr at gnu.org>
> 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
> > ghc-devs at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> _______________________________________________
> 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/20150629/114c0b24/attachment-0001.html>