[Haskell-cafe] File path programme

[robert dockins]

> 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/naming_a_file.asp
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/base/createfile.asp

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.