While true, I don't see what this has to do with the choice between PathStart and Maybe PathRoot. The types are isomorphic; we can detect and simplify the /.. case either way.
True
Because of the above problem, I'm willing to treat path fragments (Relative in both lattices) as a special case. But we still need to be able to round-trip rel:abs and abs:rel pathnames, meaning that the PathRoot type won't necessarily be a genuine cwd-independent root any more.
So we'd like to treat path fragments as a special case (eg, one can only append a path fragment), but path fragments are ambiguous with paths rooted at the CWD (of the current drive, in windows). I'm not sure how best to deal with this. It would be nice to have a separate type for path fragments so you would not have to resort to 'error' or such to prevent invalid appends, but you want relative paths to have the same type as path fragments because they can't be distinguished....
There are a few others. I took a look at MSDN earlier and was astounded.
Is there an MSDN page that actually gives a grammar, or at least a taxonomy, of Win32 pathnames? That would be useful.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/base... http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/base... The descriptions in CreateFile are as close as I could find.
Incidentally, NT doesn't do a perfect job of parsing its own pathnames. While experimenting I managed to create a file named "..", different from the directory ".." (both show up in the directory listing), which I was subsequently unable to read or delete. The command was something like "cat > ..:foo". I doubt that this behavior is by design.
That doesn't surprise me; it does make things painful, however.