System.FilePath survey

[Andrew Pimlott]

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