Hello Duncan, Wednesday, July 26, 2006, 7:34:50 PM, you wrote:
>> Exactly. I believe, a FilePath should be an algebraic datatype. >> Most operations on that don't have to be specified, because they are >> simple and have an obvious effect. Add a system specific parser and a >> system specific renderer, maybe also define a canonical format, and the >> headaches stop. What's wrong with this? > We've had this discussion before. The main problem is that all the > current IO functions (readFile, etc) use the FilePath type, which is > just a String. So a new path ADT is fine if at the same time we provide > a new IO library. That of course is an ongoing discussion in itself. i don't agree. as i said earlier today, the IO library by itself contains only a few FilePath-related functions. actually, there is only one basic function that accepts FilePath - fdOpen, and about 10 (in my current design) that calls it directly or indirectly. also there is 'show' function that should show filename. that's all. most part of library don't deal with filenames completely - be it hPutChar, hSeek or hFlush functions, so i can say that it's not great problem moreover, we can't switch all the things simultaneously, so we should provide emulators of new behavior which uses old decisions internally. for example, you can include in FPS library readFile function that accepts class but converts it to just a string for using with existing System.IO.fileOpen. in some future this implementation can de changed to "real" one using appropriate Streams.fdOpen, for example: readFile :: (FilePathClass f) => f -> IO ByteString readFile f = bracket (openFile (FilePathClass f) ReadMode) hClose (\h -> hFileSize h >>= hGet h . fromIntegral) of course, this don't make much sense, it's just an example really, filenames are mainly involved in System.Directory module. so, i propose: 1) include Stringable class in FPS lib, if possible 2) convert the FilePath module to use this class operations 3) make variant of System.Directory which uses this ADT and fucntions from FilePath module 4) move my Streams library to darcs and change fdOpen and File.show functions so they use the FilePathClass > So until we have the opportunity to change the FilePath type there does > seem to be value in providing a library that takes some of the > complexity and portability nightmares out of using the existing FilePath > type. i think, we have such opportunity >> data FilePath = Absolute RelFilePath | Relative RelFilePath >> data RelFilePath = ThisDirectory >> | File String >> | ParentOf RelFilePath >> | String :|: RelFilePath >> >> parseSystemPath :: String -> Maybe FilePath >> renderSystemPath :: FilePath -> String >> >> We can even clearly distiguish between the name of a directory in its >> parent and the directory itself. On Windows, the root directory just >> contains the drive letters and is read-only, >> drive-absolute-but-directory-relative paths are simply ignored (they are >> a dumb idea anyway). Seperator characters are never exposed, all we >> need now is a mapping from Unicode to whatever the system wants. i don't think the FilePath type is really required. imho, it should be enough to convert between various filepath-representing types. these types should include string, bytestring and system-specific type, if needed: class FilePathClass f instance FilePathClass String instance FilePathClass ByteString instance FilePathClass Word16String -- for windows cvtFilePath :: (FilePathClass f1, FilePathClass f2) => f1 -> f2 functions reading directories will return system-specific filenames representation, i.e. on windows: getDirContents :: IO [Word16String] FilePath module should work over any FilePathClass instances, so it can be used to construct filepaths from pieces and so on. then these filenames represented as Word16String values can be used to open files, create directories and so on. if one need to show filename or convert it to some system-independent format (say, for serialization), he should use cvtFilePath function > That's another portability headache - file name string encodings. > Windows and OSX use encodings of Unicode. Unix uses strings of bytes. > They are not fully inter-convertible. On Unix the traditional technique > is to keep a system file name in the original encoding and convert to > Unicode to display to the user, but the Unicode version is never > converted back to a system file name because it doesn't necessarily > convert back to the same sequence of bytes. > My point is it's not quite as simple as "just making an ADT". -- Best regards, Bulat mailto:[EMAIL PROTECTED] _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe