I (just like everyone else) have a path module, which does some things a little differently. I'm going to give a minimal working version in this literate Haskell message, along with commentary, and will package up the full code if anyone's interested. I have only used it in one little program, so I'm don't pretend all the details are right. However, I think my approach has promise, and would be grateful for your feedback. My main premise is that portably manipulating paths is _hard_, because filesystem semantics are messy and ill-specified and differ across systems; and so we should 1. be conservative in what we try to provide, and 2. use whatever techniques we can to avoid errors (by either the implementor or the user).

{-# OPTIONS -fglasgow-exts #-}

(Note that users of this module don't need glasgow-exts.)

module FSPath where import Control.Monad (liftM) import Data.List import System.Directory import System.IO

class (Read p, Show p) => Path p where

Portable path operations are class methods; that is, there is no single path type. One obvious advantage is that we can use the same (overloaded) functions on different path types, representing paths on different systems, in a single program, and never risk mixing them up. (I consider the ability to manipulate foreign paths a requirement for a production library.) A less obvious advantage, which I think may be bigger in practice, is that we can define a hierarchy of classes, each element representing different assumptions about paths (which may be common to different sets of systems). This helps us cope with the variety of path semantics in the world. In Path, I define operations that can be performed without IO, and have roughly the same, well-understood meaning on most systems on which Haskell runs:

currentPath :: p

A path representing the current working directory, eg. "." on unix.

prefixes :: p -> [(p, ChildName)]

The "parents" of this path, up until we hit something that is not a simple name, eg. "foo/../bar/baz" -> [("foo/../bar", "baz", ("foo/..", "bar")] on unix. (Actually, these are not necessarily parents, which is why I didn't name the method that.)

addChild :: Monad m => p -> ChildName -> m p

Add a single child, eg. "foo/bar" -> "baz" -> "foo/bar/baz". I use Monad for possible failure, say if the child were not a plain name, eg. ".." on unix.

append :: Monad m => p -> p -> m p

The second path relative to the first. There are some ambiguous cases on Windows that perhaps should fail. That's it for pure path ops. I know that typically path libraries have more, but most of them seem either to me unnecessary, redundant or of questionable portability. (Perhaps those that are less portable could be added in subclasses.) I'm sure that other people will differ, so I would welcome use cases for additional operations you find useful. ChildName is just

type ChildName = String

for now; maybe it should be part of the class? I define another class containing IO operations. The module should only give out instances that represent paths native to the currently running system.

class Path p => NativePath p where

I haven't dared to redesign how IO uses paths, but this module should be easily adapted to such a redesign. I suppose eventually all filesystem IO operations could be methods in this class, and the functions taking FilePath deprecated or removed. For now, I just include two methods that might need special treatment:

getChildren :: p -> IO [p] canonicalize :: p -> IO p

and for other IO, define a helper:

filePathIO :: NativePath p => (FilePath -> IO a) -> (p -> IO a) filePathIO f p = f (show p)

To get an instance of these classes that's right for the current system, I use some of the (more elementary) techniques from Ken and Oleg's "Implicit Configurations". The user supplies a function that is polymorphic in the path type, to a function that runs it on the native type. Here are two variants (defined later):

withNativePath :: FilePath -> (forall p. NativePath p => p -> IO r) -> IO r withNativeCurrentPath :: (forall p. NativePath p => p -> IO r) -> IO r

The argument to the user's function has the native type, and unification automatically propagates that type to other values. This avoids the need for an explicit dictionary of operations. Eg., to read two filenames, append them, and open the result:

example1 :: IO Handle example1 = do path1 <- getLine withNativePath path1 (\path1 -> do path2 <- readLn path <- append path1 path2 filePathIO (flip openFile ReadMode) path)

The overloaded function readLn reads a path of the right type. For the instances of these classes, I define algebraic data types. The alternative, retaining the string representation, would have some advantages: It would probably perform better, and moreover it would not require parsing the whole string for some operations, so there is less chance of the parser stumbling on an unfamiliar construct. On the other hand, it is safer and saner to fully parse paths up-front, and other path libraries (eg. in Boost) seem to do that. A string representation encourages thinking about what the path looks like, rather than what it means. What clinches the deal is that path manipulation on an algebraic type is much more comprehensible than on a string. In libraries (in various languages) where every operation parses the path string, I have to stare hard at the code to understand what it does and convince myself it's right. So I agree with a common sentiment expressed in this thread: That's not the Haskell way! There is also the question of whether to use a single "generic" algebraic type, or let each system define its own. The former might be considered to simplify the API, because users have only one type to deal with. But since I've already chosen the typeclass design, there's no need to restrain myself to one type. Even so, I first tried to define a generic type, hoping it would simplify the implementation. I found it did the opposite, because every system used different parts of the generic type, and for different purposes, so it was hard to be sure I had all the cases right. Further, it meant that anyone wanting to change the generic type for the benefit of one system would have to be careful not to break all the others. Finally, at some level, paths on different systems are fundamentally different, the bytes-on-unix/unicode-on-windows issue a prime example. So I defined one type per system. Here's the type for unix:

data UPath = UPath UStart [UElement] -- from leaf deriving Eq

data UStart = UAbsolute | USlashSlash | URelative deriving Eq

data UElement = UChild ChildName | UParent deriving Eq

The implementation of class operation is pretty nice on this representation, although there are still some tricky cases.

uCurrentPath :: UPath uCurrentPath = UPath URelative []

uPrefixes :: UPath -> [(UPath, ChildName)] uPrefixes (UPath start es) = foldr prefix [] (init (tails es)) where prefix (UChild s:es) ps = (UPath start es, s) : ps prefix (UParent:_) _ = []

uAddChild :: Monad m => UPath -> ChildName -> m UPath uAddChild (UPath start es) s = case reads s of [(e@(UChild _), "")] -> return (UPath start (e:es)) _ -> fail "not a unix child"

uAppend :: UPath -> UPath -> UPath uAppend p p'@(UPath UAbsolute _) = p' uAppend p p'@(UPath USlashSlash _) = p' uAppend (UPath UAbsolute []) (UPath URelative es') = UPath UAbsolute (dropWhile (UParent ==) es') uAppend (UPath USlashSlash []) (UPath URelative es') = UPath USlashSlash (dropWhile (UParent ==) es') uAppend (UPath start es) (UPath URelative es') = UPath start (es' ++ es)

instance Path UPath where currentPath = uCurrentPath prefixes = uPrefixes addChild = uAddChild append p1 p2 = return (uAppend p1 p2)

uGetChildren :: UPath -> IO [UPath] uGetChildren p = do ss <- getDirectoryContents (show p) return (concatMap (uAddChild p) ss)

uCanonicalize :: UPath -> IO UPath uCanonicalize p = canonicalizePath (show p) >>= readIO

instance NativePath UPath where getChildren = uGetChildren canonicalize = uCanonicalize

Note that the unix functions (and perhaps also the constructors) can be exported, for anyone who wants to operate specifically on unix paths, and take advantage of their full structure. The IO operations and NativePath instance should probably be ifdef'ed out on non-unix. (I don't like ifdefs that change the signature of a module, but I think it's passable here.) If you want to try this module for now, you have to use unix. :-)

withNativePath p f = (readIO p :: IO UPath) >>= f withNativeCurrentPath f = f (currentPath :: UPath)

Here's the example of rm -rf:

rmTree :: FilePath -> IO () rmTree s = withNativePath s rm where rm p = doesDirectoryExist' p >>= \b -> if b then rmDir p else rmFile p where rmDir p = do getChildren p >>= mapM rm removeDirectory' p rmFile p = removeFile' p doesDirectoryExist' = filePathIO doesDirectoryExist removeFile' = filePathIO removeFile removeDirectory' = filePathIO removeDirectory

Lastly, the read and show functions. (You can stop now.)

instance Show UPath where show (UPath UAbsolute []) = "/" show (UPath UAbsolute es) = '/' : join '/' (map show (reverse es)) show (UPath USlashSlash []) = "//" show (UPath USlashSlash es) = "//" ++ join '/' (map show (reverse es)) show (UPath URelative []) = "." show (UPath URelative es) = join '/' (map show (reverse es))

instance Show UElement where show (UChild s) = s show UParent = ".."

instance Read UPath where readsPrec _ "" = fail "empty string is not a unix path" readsPrec _ s = let (slashes, s') = span (== '/') s es = map fst (concatMap reads (split '/' s')) es' = dropWhile (UParent ==) es in case slashes of "//" -> return (UPath USlashSlash (reverse es'), "") ('/':_) -> return (UPath UAbsolute (reverse es'), "") [] -> return (UPath URelative (reverse es), "")

instance Read UElement where readsPrec _ "" = fail "empty string is not a unix element" readsPrec _ "." = fail ". is not a unix element" readsPrec _ ".." = return (UParent, "") readsPrec _ s | any ('\0' ==) s = fail "\\NUL is not allowed in unix paths" | otherwise = return (UChild s, "")

split :: Eq a => a -> [a] -> [[a]] split sep [] = [[]] split sep (x:xs) | x == sep = [] : split sep xs | otherwise = let (r:rs) = split sep xs in (x:r) : rs

join :: a -> [[a]] -> [a] join sep [x] = x join sep (x:xs) = x ++ [sep] ++ join sep xs

Andrew