On Wed, Jan 26, 2005 at 01:34:39PM -0000, Simon Marlow wrote:
... We can therefore:
(a) make System.IO.FilePath be the new type, which is different from, and incompatible with, IO.FilePath. Similarly for System.IO.openFile, System.Directory.removeFile, and so on.
(b) or just define a new type, and force you to insert read/show to convert where necessary, eg. before calling openFile.
(a) is kind of the right thing, but (b) is a lot less painful in the short term. Since we'll be migrating to a new IO library at some point, (b) is probably fine (the new IO library can use the new FilePaths exclusively), but we'll need to migrate System.Directory too.
One thing I've been wishing for some time (as long as we're discussing a replacement for FilePath) was to have a FilePath class, which would allow me to use my FastPackedStrings with the IO routines. It seems silly to have a byte-oriented filepath, convert it into a String and then have the IO library convert back again to a byte-oriented string to call the C library. I've wished there were a class FilePath f where toStringFilePath :: f -> String withCStringFilePath :: f -> (CString -> IO a) -> IO a or something like that (where the withCStringFilePath could have a default written in terms of toStringFilePath). It's a shame when I use ffi for some of my IO (which of course always requires CStrings) and haskell IO libraries which always require Strings to keep having to convert back and forth. Alas, darcs does enough "quick" calls to stat (doesFileExist, etc) that the cost isn't negligible. Eventually I'll rewrite a lot of this to just use the ffi (since I want to use lstat anyways, or its windows equivalent), but it would be nice (eventually) not to have to do this. But how painful would it be for the System.IO functions to have types such as readFile :: FilePath a => a -> String ? -- David Roundy http://www.darcs.net