On 2/6/06, Simon Marlow
Isaac Jones wrote:
Has anyone yet volunteered to do the hard work of defining an ADT and made a proposal for how it should interact w/ the System.IO functions?
I think that lacking a FilePath module is a serious problem that is holding haskell back. Lots of languages use String for filepath, like Python, which is hugely popular for these uses, but has nothing on Haskell, IMO, except this single library.
Lots of people have written home-grown FilePath modules. How long can we wait for an implementation to appear?
The reason we can't just go right ahead and do The Right Thing (i.e. introduce a new ADT for FilePaths) is because it touches so much other stuff, including stuff that also needs revising, so it doesn't feel right to just fix the FilePath library.
Experience with GHC releases has left me with the opinion that it's better to group breaking changes together rather than dribble them out - people only have to modify their code once, and conditional compilation gets fewer cases.
So I'm of the opinion that introducing an ADT for FilePaths is something that should wait until the I/O library is revised. In the meantime, we should include a String-based Data.FilePath library in Haskell'. It's not as elegant, but it's terribly practical, and that's one goal of Haskell'.
As a first step, can someone package up Data.FilePath as a Cabal package so that at least we can all start using the same one?
Already done. Darcs repository: http://scannedinavian.com/~lemmih/FilePath/ Tarball: http://hackage.haskell.org/packages/FilePath-0.1.0.tgz -- Friendly, Lemmih