Hi
> I want to make sure a filename is valid. For example, "prn" and "con" This is another rat's nest, so I suggest that it be dealt with separately from the basic filepath module. The notion of "valid" is squishy: It depends entirely on what you intend to do with the path.
Its a rats nest to do it properly, but some very basic idea of "does this path have things which there is no way could possibly be in a file" - for example c:\|file is a useful thing to have. By making it pure, there is no risk of the result being different. I see the isValid guarantee more as a False means it definately isn't valid, rather than the other way round.
> In this library proposal, there are a bunch of "xxxDrive" functions > that many Unix-oriented programmers are sure to ignore because they are > no-ops on Unixy systems. Even on Windows, they are not very useful: I strongly agree about this. The temptation in path modules seems to be to throw in everything you can think of (without specifying any of it precisely), just in case someone finds it useful.
The drive functions stand on their own as a chunk, and are possibly not well suited to a Posix system, but are critical for a Windows system. Ignoring these, which would you consider worthy of removal? Some are strictly "redundant", but quite useful - for example isAbsolute/isRelative which are the negation of each other. I have tried to specify the functions precisely, and I use this specification as a test suite. Currently there are 114 properties in this test suite, all can be seen on the haddock documentation. If you consider any function to be ambiguously specified, please say which one and I'll add extra tests until it gives you no suprises at all. QuickCheck rules :)
I tried to export a minimal set of operations that seem to me sufficient for everything not very platform-specific (though I am interested in counterexamples):
Anything to do with file extensions? Its also important (I feel) for people to have easy access to common operations, but I guess that is a design decision. Thanks Neil _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe