Abstract FilePath Proposal

[Gershom B]

+1 on the original proposal, sans variations. The advantage is that it provides a very clear and smooth upgrade path, that with correct signaling can be nearly seamless.

As argued, it isn’t about enforcing the “right” semantics, which can be overlaid with further proposals or even in userland libraries — it is that the current datatype is just plain wrong for capturing the various weird things that filepaths can really be in practice, so to even have the possibility of putting in place semantics that are “more correct” we need to have the right sort of opaque type to begin with. Since this proposal is designed to be the smoothest way to get us over that hump, I support it.

—gershom


On June 28, 2015 at 7:38:06 PM, Bart Massey (bart.massey at gmail.com) wrote:
> -1 on this proposal in all its variations right now. There seems to be no
> strong consensus on the positive nature of any of the proposed changes at
> this point, and folks seem to disagree on the scope and content of the
> changes. We should leave well enough alone until someone has a proposal
> most of us can agree is awesome.
>  
> On Sun, Jun 28, 2015 at 10:05 AM wrote:
>  
> > One other point, while still maintaining +0 on the proposal itself:
> >
> > This proposal is likely to break lots and lots of code a la the FTP, and
> > we all remember the unpleasant surprise that the community had with that
> > one.
> >
> > If libraries@ agrees this is a worthwhile change, I think we need to let
> > the community vote on it and its deprecation cycle.
> >
> > Tom
> >
> >
> > El Jun 27, 2015, a las 3:36, Herbert Valerio Riedel  
> > escribió:
> >
> > > On 2015-06-26 at 18:22:16 +0200, Henning Thielemann wrote:
> > > [...]
> > >>>> type FilePath = String
> > >>>>
> > >>>> into an abstract/opaque data type instead.
> > >>>
> > >>> Has someone else tried the pathtype package?
> > >>> http://hackage.haskell.org/package/pathtype
> > >>
> > >> Hm, your last point "Decisions assumed by this Proposal" seems to
> > >> mean, that you want to leave out more specialised types from this
> > >> proposal. That is, dir/file distinction might be defined on top of the
> > >> new FilePath type.
> > >
> > > Yes, because the proposal is meant to only make the smallest incremental
> > > change needed (i.e. change FilePath datatype, provide conversion
> > > functions) to to achieve the primary goals (reduce space/time overhead &
> > > make it a distinct type from String) in a way suitable for a future
> > > Haskell Report, while trying to stay close enough that you can still
> > > write code that works with both the H2010 and a AFPP definition of
> > > `FilePath`
> > >
> > > Trying to redesign the FilePath type to also include dir/file
> > > distinction seemed too daunting, as there's quite some additional
> > > design-space area to explore (do drive-letters deserve a separate type?
> > > do we use DataKinds? What invariants can/shall be represented at the
> > > type-level? what errors are caught at the type-level, which are caught
> > > at runtime? etc...), parts of which may require type-system extensions,
> > > while just having a KISS-style opaque FilePath evades this.
> > >
> > > _______________________________________________
> > > Libraries mailing list
> > > Libraries at haskell.org
> > > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
> > _______________________________________________
> > Libraries mailing list
> > Libraries at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
> >
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>