[Haskell-cafe] RE: ANN: System.FilePath 0.9

[Chris Kuklewicz]

First, http://java.sun.com/j2se/1.5.0/docs/api/java/io/File.html may be useful 
to compare to.  I learned "C:\" is an absolute and "C:" is a relative path.

What are the use cases? I can see four different "types" of file paths that one 
will want to manipulate.  The following are all pure functions:

(Main) Local system compatibility: I must understand all the local files
   1 create roots of the local filesystem(s) (e.g. "C:\")
   2 remove the last file or path element (easy except for symlinks).
   3 create a new file or directory name at the end of a path and know that this 
is valid for the local filesystem (i.e. has no invalid or unencodable characters).
   4 Make a way to get the local list of invalid characters
   5 Provide an "isValid" test (and maybe a "rootValid" test)
   6 Provide an  "invalidToSuggestedValid" function that applies some policy for 
ensuring new paths can be coerced into a valid form. (Aside from LPT1 insanity?)
The URL solution of %FF from rfc1630 could be used.
   7 parsing the names of paths and files with respect to the local system, so 
you can handle a directory listing. (Unicode problems go here)

(Secondary) Maximal cross platform compatibility: I want mine to work everywhere
   Provide 2-6 but for a conservative union of all bad characters.  Handling the 
"roots" would be trickier.

(Tertiary) Specific platform compatibility: I want to work with platform Foo
   Provide 2-6 but for the platform the user specifies.  This may or may not be 
the current platform.

(Special) Handle conversion to and from "file://" URI's

The (Secondary) could be accomplished as a special case of (Tertiary) by 
specifying the platform "Most" for instance.

The (Main) could be accomplished as a special case of (Tertiary) by specifying 
the platform "Local".

None of the above depend on IO.  None of the above really care about String vs 
ADT.  The only one that truly and deeply cares about character set encoding is 
#7 on the local system.  Mainly, the above just provides sets of invalid characters.

A "makeCanonical" pure function could remove "." and ".." in the syntactic way. 
  But I can't see what else it could do without IO.

Any IO based function can only be part of the (Main) Local system compatibility 
domain of operations.  And the guarantees are weak due to race conditions.

E.g. the "makeCanonical_IO" is a fancier operation that removes "." and ".." 
based on symlinks and upper/local case matching based on what is in the filesystem.