Would someone like to take up the reigns on the design for the new library?
I don't feel I know enough about the corners of DOS, Windows, and MacOS Classic filesystems to take up the challenge. But here's a quick sketch of the kind of thing I had in mind, based on Ben's suggestion:
having an ADT for paths would not break any code, if what that means is that we provide
parsePath :: String -> Maybe Path showPath :: Path -> Maybe String
and various (new) functions operating on the Path type.
So let's define a new algebraic datatype something like: data Path = Unix { absolute :: Bool , dirnames :: [String] , basename :: String , extensions :: [String] } | DOS { absolute :: Bool , drive :: Maybe Char , dirnames :: [String] , basename :: String -- max 8 Chars , extension :: String -- max 3 Chars } -- | Win32 ... -- | MacOSClassic .... -- | VMS | CPM | Amiga | ARM .... The implementation of parseFilePath :: Prelude.FilePath -> Maybe System.Path is probably quite involved, but the Show instance should be more straightforward, something like: instance Show FilePath where show (Unix abs dirs name exts) = (if abs then ('/':) else id) (concat (intersperse "/" (dirs++[basename])) ++ concat (intersperse "." exts)) show (DOS abs drive dirs name ext) = (maybe "" (\c->[c,':']) drive) ++ (if abs then ('\\':) else id) (concat (intersperse "\\" (dirs++[basename])) ++"."++ext) The signatures of various of the current manipulation functions would need to change: - splitFileName :: FilePath -> (String, String) + splitFileName :: Path -> (Path, String) - splitFileExt :: FilePath -> (String, String) + splitFileExt :: Path -> (Path, String) - joinFileName :: String -> String -> FilePath + joinFileName :: Path -> String -> Path - joinPaths :: FilePath -> FilePath -> FilePath + joinPaths :: Path -> Path -> Maybe Path ... and so on. Regards, Malcolm