[ I tried to send this through the fa.haskell USENET group but apparently it did not go through] I kind of expect that a Haskell library for file paths will use the type system to ensure some useful properties about the paths. For example, when writing security-conscious software I often want to be able to distinguish between absolute, ascending (paths with leading "../" and similar items), and decending paths (paths that contain no "../"). I want to make sure a filename is valid. For example, "prn" and "con" are not valid path elements for normal files on Windows, certain characters are not allowed in filenames (depending on platform), some platforms may require paths to be escaped in different ways. I see there is a "isValid" function and even a (magical) "makeValid" function, but they do not report what was wrong with the filename in the first place. Furthermore, it isn't clear from the documentation how these functions determine whether a filename is valid. Many people might be familiar with Joel Spolsky's article "Making Wrong Code Look Wrong" at http://www.joelonsoftware.com/articles/Wrong.html . If you read that article, you will see that advocates a variable naming convenctions to distinguish between HTML-escaped "safe" and non-escaped "unsafe" strings. In Haskell, we can do much better than that by using convenient strong static typing to enforce such constraints. We should be able to use type signatures to ensure that we are operating on syntactically valid paths of a certain form. For example, a function's type should indicate that it expects an absolute path, or a relative path that doesn't use "../../.." to decend into parent/sibling directories unexpectedly, which is a common exploit technique. IMO, safety is the most important issue regarding file paths and it is not addressed in this library as far as I can see. Writing code to handle these issues is tedious, error-prone, and boring to write despite being critical. It isn't the kind of code that you want to just download off of some guy's webpage. Basically, it is exactly the type of thing that belongs in a standard library. In this library proposal, there are a bunch of "xxxDrive" functions that many Unix-oriented programmers are sure to ignore because they are no-ops on Unixy systems. Even on Windows, they are not very useful: Windows software almost never cares what drive a directory is on, especially because the directory might not be on a drive at all (for example, a UNC network path "\\foo\bar" has no "drive" component but it is an absolute path). Really, Windows software usually works similarly to Unixy software in this regard--the big difference is that Unixy systems have one root path, whereas Windows systems can have many, many root paths (drives and UNC's). - Brian