
On Wed, Jan 26, 2005 at 10:20:12PM -0500, Robert Dockins wrote:
class (Show p) => Path p where isAbsolute :: p -> Bool isRelative :: p -> Bool isRelative = not . isAbsolute basename :: p -> String parent :: p -> p pathAppend :: p -> p -> p pathExtend :: p -> String -> p pathSeparator :: p -> Char pathParser :: Parser p parsePath :: String -> p parsePath x = case parse pathParser "" x of Left e -> error $ show e Right x -> x
Warning: I'm not interested in a path parsing/combining library, so my criticisms are perhaps unrelated to your goals. One thing that I'd be interested in seeing for any Path class would be a simple instance for FilePath (or String, if you want to imagine FilePath will be changed). Not everyone will want the overhead of a massively heavyweight Path datatype. I'd actually rather have something lighter-weight than String (think PackedString), since FilePaths can take up a good chunk of darcs' memory. Another thing to consider is that any Path class *needs* to have a conversion to C string (probably of the "with" variety). Even on Windows, where apparently a FilePath is not a sequence of bytes, we'd like to be able to use the FFI to call the C standard library, and it would be nice to be able to access the same file both via the FFI and also via the haskell standard libraries. Of course, this means we'd want a similar conversion the other way. I guess it's just that I'm more concerned with making possible what is currently impossible (according to the library standards)--that is, using FFI and IO on the same file--rather than just adding utility features that application developers could have written themselves. I suppose we don't need a class for this, all we need is a couple of functions to convert between FilePath and CString. -- David Roundy http://www.darcs.net