<div dir="ltr">Normalization is a very hairy issue, which is not just platform specific but also filesystem specific. Mac OS X is probably the worst of all words in that respect, where HFS+ will do NFD normalization and may or may not have case sensitivity depending on how that partition was formatted. Network file shares and disk images may or may not have case sensitivity and can use either NFD or NFC normalization based on mount options.<div><br></div><div>Contrary to statements earlier in the thread, NFD normalization happens on HFS+ filesystems (the default) regardless of whether you're using POSIX APIs or not. It's easy to prove this to yourself by creating a file with U+00c9 (LATIN SMALL LETTER E WITH ACUTE) in the name (from any of the APIs) and you'll see it come back out (e.g. from readdir) as two code points: 'e' and then U+0301 (COMBINING ACUTE ACCENT). It'll also do some weird transformations to file names that contain byte sequences that are not valid UTF-8.</div>
<div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Jun 28, 2015 at 12:05 PM, Edward Kmett <span dir="ltr"><<a href="mailto:ekmett@gmail.com" target="_blank">ekmett@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Worse there are situations where you absolutely _have_ to be able to use <font face="monospace, monospace">\\?\</font> encoding of a path on Windows to read, modify or delete files with "impossible names" that were created by other means.<div><br></div><div>e.g. Filenames like AUX, that had traditional roles under DOS cause weird interactions, or that were created with "impossibly long names" -- which can happen in the wild when you move directories around, etc.<div><br></div><div>I'm weakly in favor of the proposal precisely because it is the first version of this concept that I've seen that DOESN'T try to get too clever with regards to adding all sorts of normalization and this proposal seems to be the simplest move that would enable us to do something correctly in the future, regardless of what that correct thing winds up being.</div></div><span class="HOEnZb"><font color="#888888"><div><br></div><div>-Edward</div></font></span></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Sun, Jun 28, 2015 at 8:09 AM, David Turner <span dir="ltr"><<a href="mailto:dct25-561bs@mythic-beasts.com" target="_blank">dct25-561bs@mythic-beasts.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div dir="ltr">Hi,<div><br></div><div>I think it'd be more robust to handle normalisation when converting from String/Text to FilePath (and combining things with (</>) and so on) rather than in the underlying representation.</div><div><br></div><div>It's absolutely crucial that you can ask the OS for a filename (which it gives you as a sequence of bytes) and then pass that exact same sequence of bytes back to the OS without any normalisation or other useful alterations having taken place.</div><div><br></div><div>You can do some deeply weird stuff in Windows by starting an absolute path with \\?\, including apparently using '.' and '..' as the name of a filesystem component:</div><div><br></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><span style="color:rgb(69,69,69);font-family:'Segoe UI','Lucida Grande',Verdana,Arial,Helvetica,sans-serif;font-size:14px;line-height:20.0060005187988px">Because it turns off automatic expansion of the path string, the "\\?\" prefix also allows the use of ".." and "." in the path names, which can be useful if you are attempting to perform operations on a file with these otherwise reserved relative path specifiers as part of the fully qualified path.</span></div></blockquote><div><br></div><div>(from <a href="https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx" target="_blank">https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx</a>)</div><div><br></div><div>I don't fancy shaking all the corner cases out of this. An explicit 'normalise' function seems ok, but baking normalisation into the type itself seems bad.</div><div><br></div><div>Cheers,</div><div><br></div><div>David</div><div><br></div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On 28 June 2015 at 11:03, Boespflug, Mathieu <span dir="ltr"><<a href="mailto:m@tweag.io" target="_blank">m@tweag.io</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Neil,<br>
<br>
why does the proposal *not* include normalization?<br>
<br>
There are four advantages that I see to making FilePath a datatype:<br>
<br>
1. it makes it possible to implement the correct semantics for some<br>
systems (including POSIX),<br>
2. it allows for information hiding, which in turn helps modularity,<br>
3. the type is distinct from any other type, hence static checks are stronger,<br>
4. it becomes possible to quotient values over some arbitrary set of<br>
identities that makes sense. i.e. in the case of FilePath, arguably<br>
"foo/bar//baz" *is* "foo/bar/baz" *is* "foo//bar/baz" for all intents<br>
and purposes, so it is not useful to distinguish these three ways of<br>
writing down the same path (and in fact in practice distinguishing<br>
them leads to subtle bugs). That is, the Eq instance compares<br>
FilePath's modulo a few laws.<br>
<br>
Do you propose to forego (4)? If so why so?<br>
<br>
If we're going through a deprecation process, could we do so once, by<br>
getting the notion of path equality we want right the first time?<br>
Contrary to type indexing FilePath, it seems to me that the design<br>
space for path identities is much smaller. Essentially, exactly the<br>
ones here: <a href="https://hackage.haskell.org/package/filepath-1.1.0.2/docs/System-FilePath-Posix.html#v:normalise" rel="noreferrer" target="_blank">https://hackage.haskell.org/package/filepath-1.1.0.2/docs/System-FilePath-Posix.html#v:normalise</a>.<br>
<br>
Best,<br>
<br>
Mathieu<br>
<div><div><br>
<br>
On 27 June 2015 at 12:12, Neil Mitchell <<a href="mailto:ndmitchell@gmail.com" target="_blank">ndmitchell@gmail.com</a>> wrote:<br>
> Hi Niklas,<br>
><br>
> The function writeFile takes a FilePath. We could fork base or tell everyone<br>
> to use writeFile2, but in practice everyone will keep using writeFile, and<br>
> this String for FilePath. This approach is the only thing we could figure<br>
> that made sense.<br>
><br>
> Henning: we do not propose normalisation on initialisation. For ASCII<br>
> strings fromFilePath . toFilePath will be id. It might also be for unicode<br>
> on some/all platforms. Of course, you can write your own FilePath creator<br>
> that does normalisation on construction.<br>
><br>
> Thanks, Neil<br>
><br>
><br>
> On Saturday, 27 June 2015, Niklas Larsson <<a href="mailto:metaniklas@gmail.com" target="_blank">metaniklas@gmail.com</a>> wrote:<br>
>><br>
>> Hi!<br>
>><br>
>> Instead of trying to minimally patch the existing API and still breaking<br>
>> loads of code, why not make a new API that doesn't have to compromise and<br>
>> depreciate the old one?<br>
>><br>
>> Niklas<br>
>> ________________________________<br>
>> Från: Herbert Valerio Riedel<br>
>> Skickat: 2015-06-26 18:09<br>
>> Till: <a href="mailto:libraries@haskell.org" target="_blank">libraries@haskell.org</a>; <a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
>> Ämne: Abstract FilePath Proposal<br>
>><br>
>> -----BEGIN PGP SIGNED MESSAGE-----<br>
>> Hash: SHA1<br>
>><br>
>> Hello *,<br>
>><br>
>> What?<br>
>> =====<br>
>><br>
>> We (see From: & CC: headers) propose, plain and simple, to turn the<br>
>> currently defined type-synonym<br>
>><br>
>> type FilePath = String<br>
>><br>
>> into an abstract/opaque data type instead.<br>
>><br>
>> Why/How/When?<br>
>> =============<br>
>><br>
>> For details (including motivation and a suggested transition scheme)<br>
>> please consult<br>
>><br>
>> <a href="https://ghc.haskell.org/trac/ghc/wiki/Proposal/AbstractFilePath" rel="noreferrer" target="_blank">https://ghc.haskell.org/trac/ghc/wiki/Proposal/AbstractFilePath</a><br>
>><br>
>><br>
>><br>
>> Suggested discussion period: 4 weeks<br>
>> -----BEGIN PGP SIGNATURE-----<br>
>> Version: GnuPG v1<br>
>><br>
>> iQIcBAEBAgAGBQJVjXkZAAoJELo8uj/+IrV0WXUP/0romoKazwLbQpaMAKgCNZon<br>
>> BsY8Di44w6rkbdBXoky0xZooII8LJJyQfexH0BLRYEVLZFy0+LB8XzpPt8Ekg526<br>
>> YlY4x0qFm9oiJbJDMqHUnb6z6Lr2KxzBcV37drTPbltUA+HB49DUVkkPbvHimpL2<br>
>> 28SIyhAr4fN6fLpGcFAkv6Rcs0mkvnTp7vsC0HNyshmGi6qQ+C+eB4mklQzWOPcn<br>
>> koHZ2wtI8AJmyTdHKcXKAIFM0r+xl4MJ5445IvDjvIuGXZCzybXMw9Ss/4wSG3VN<br>
>> qSIJVEDGZXrBCc12fPxPEB0Bqx9MIVytjplXKIo8rFrk93h3at9t9kDM26z+9PZ5<br>
>> KYnEdjRKF4KL4j+3xqJDOEJT15GVRbGRRzb9A8xH0YIQ0S3Q3pt1PAfla1Hss75+<br>
>> NRQgfowZYryL9dfCkAj2XNfdQ+pUk25N3bNig11se+zjk2JO77QRM0u3GOYZ9+CU<br>
>> tSlwhtIMF32xnjgQyWE5yBBiEg3/Y+S+809tVaPseUEzkQJXMGq5TFxBrN6bj1Vm<br>
>> awr6QghThKjeoRwky5bmFn/gept/lbYN6VV5B6gNznGP5xgFrmvVtmjbQJBRMYCv<br>
>> aEUnrYqxkkbIddJjD5gl771/LWH4M2F1yBgJjfiZw2paEVAXKxEr327LsbOQaPdb<br>
>> HjIPRrJbVK9AABo4AZ/Y<br>
>> =lg0o<br>
>> -----END PGP SIGNATURE-----<br>
>> _______________________________________________<br>
>> ghc-devs mailing list<br>
>> <a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
>> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
><br>
><br>
> _______________________________________________<br>
> ghc-devs mailing list<br>
> <a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
><br>
_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
</div></div></blockquote></div><br></div>
</div></div><br></div></div><span class="">_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
<br></span></blockquote></div><br></div>
<br>_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
<br></blockquote></div><br></div>