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
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
