Abstract FilePath Proposal

[Yitzchak Gale]

I am strong -1 on this proposal, due to the arguments
of Joachim, unless we are getting the semantics right.
Are we?

By semantics, I mean just the lowest-level definition
of what a path is made of.

On POSIX, it's a raw string of bytes, with interpretation
in any human-readable way delegated to the application.

On Mac OS X, it's normalized Unicode. The important
point is *normalized* - if you create a FilePath from two
different Unicode strings that have the same normalized
form, the result FilePaths must be equal on Mac OS X.

On Windows, it's UTF-16. Basically, modulo the quirks.

Correct semantics means:

1. There are different FilePath types for each platform,
because the semantics of a path are vastly different for each.

2. By default, the FilePath for the current platform is used.
But the FilePaths for other platforms are also available,
and there is a simple API for best-effort conversion
between them.

Will this proposal provide that? If not, don't do this to us.
Please.

Joachim Breitner wrote:

> unless proven wrong, I assume that this breaks lots of code. So by
> default, I am doubtful towards that proposal.
>
> Also, the argument about inefficiency does not convince me. In a
> Prelude where "type String = [Char]", this is – as bad as it may be –
> consistent and expected. Just like you manually have to reach out for
> dedicated string types if you want efficient Haskell, you can manually
> reach out for dedicated FilePath libraries. I doubt that it is a good
> idea to fix the String problem in small, isolated chunks.
>
> However, the argument that, depending on the system, "type FilePath =
> String" is simply wrong (because the semantics of file paths are not
> unicode points), is one that I buy in. On such systems, the Prelude is,
> in a moral sense, wrongly typed, and the situation is comparable to a
> hypothetical "type String = [Word8]" – which is just wrong in a world
> of unicode. So for me, the faithful representation of system filepaths
> makes this proposal interesting. I like it when Haskell “gets it
> right”.
>

The problem is that I'm not sure this proposal "gets it right".
And if not, I agree with your arguments that this proposal
would not be worth the pain.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20150627/a68c644b/attachment-0001.html>