On Mon, Feb 06, 2006 at 03:36:17PM +0000, Simon Marlow wrote:
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'.
I don't see why merely introducing an ADT would break anyone's code, as there is no existing standard filepath model, therefore no code to break! The code I posted works with the current IO library and uses an ADT. I also think it has the potential to be compatible with a redesigned IO library. I further believe in incremental change when possible. So if it's possible to try out a "better" approach to filepaths (whatever "better" may be) without redesigning IO, IMO that's exactly what we should do. Now it may be that the need for a filepath library is so great, and "better" approaches sufficiently untested, that we should use whatever exists and works right now. But that is a separate question. Andrew