Abstract FilePath Proposal

[amindfv at gmail.com]

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 <hvr at gnu.org> 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