[Haskell-cafe] File path programme

[David Roundy]

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