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.