andrew at pimlott.net
Mon Feb 6 14:36:50 EST 2006
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
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.
More information about the Libraries