simonmarhaskell at gmail.com
Wed Feb 8 04:39:38 EST 2006
Andrew Pimlott wrote:
> 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
Sure there's an existing filepath model - the IO module contains this:
type FilePath = String
and all filesystem operations work in terms of FilePath. Changing the
representation of FilePath would break code.
> 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.
Yes, but you didn't change FilePath, you added some new file path types
and operations, so anyone using your library has to convert from one to
the other in order to call exisitng IO operations.
Certainly that's an acceptable solution, but not my prefferred solution
because we end up with two kinds of path types, albeit temporarily.
This will seem confusing and unnecessary to newcomers. However, it does
have the advantage of being "upwards compatible" as you point out, so
it's a difficult judgement call. (I admit I haven't groked your code
fully yet, BTW)
More information about the Libraries