On 2/6/06, Simon Marlow <[EMAIL PROTECTED]> wrote: > 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 _______________________________________________ Haskell mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell
