Peter Simons wrote:
The module currently knows only _relative_ paths. I am still experimenting with absolute paths because I have recently learned that on Windows something like "C:foo.txt" is actually relative -- not absolute. Very weird.
"\foo.txt" is also relative on Win32. And "con.txt" is absolute.
There also is a function which changes a path specification into its canonic form, meaning that all redundant segments are stripped. So although two paths which designate the same target may not be equal, they can be tested for equivalence.
Again, while this transformation may be useful in some cases, it is not a canonicalization operation. "foo/../bar" and "bar" do not in general refer to the same file, and "foo" and "foo/." are not in general equivalent. We shouldn't encourage these misconceptions in the library, even if we do provide a path-collapsing transformation along these lines. Other comments: 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. 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. It seems artificial to distinguish read :: String -> RelPath Windows from read :: String -> RelPath Posix in this way. In general, this library doesn't seem to deal with any of the hard cases. The devil's in the details. -- Ben