Sven Panne writes:
Hmmm, I'm not really sure what "equivalence" for file paths should mean in the presence of hard/symbolic links, (NFS-)mounted file systems, etc.
Well, there is a sort-of canonic version for every path; on most Unix systems the function realpath(3) will find it. My interpretation is that two paths are equivalent iff they point to the same target. You (and the others who pointed it out) are correct, though, that the current 'canon' function doesn't accomplish that. I guess, I'll have to move it into the IO monad to get it right. And I should probably rename it, too. ;-) Ben Rudiak-Gould writes:
The Read and Show instances aren't inverses of each other. I don't think we should be using Read for path parsing, for this reason.
That's fine with me; I can change that.
I don't understand why the path ADT is parameterized by segment representation, but then the Posix and Windows parameter types are both wrappers for String.
No particular reason. I just wanted to make the library work with a simple internal representation before doing the more advanced stuff. It is experimental code.
It seems artificial to distinguish read :: String -> RelPath Windows from read :: String -> RelPath Posix in this way.
I think it's pretty neat, actually. You have a way to specify what kind of path you have -- and the type system distinguishes it, not a run-time error. Peter