I kind of expect that a Haskell library for file paths will use the type system to ensure some useful properties about the paths. I am specificially concentrating on type FilePath = String, because
Hi Brian, that is how it is defined by Haskell 98. And consequently that's how it works with readFile/writeFile/appendFile etc. Perhaps a far better solution to this would not be to hack these kind of guarantees in at the filepath level, but have a restricted IO monad that only lets you perform operations inside certain directories, or only lets you read/write files. I know that both House and Halfs use these techniques. Without too much effort Yhc (for example) could be modified to perform restricted IO operations (only on certain directories etc). You seem to want to distinguish between relative, relative down only and absolute paths. By putting this in the filepath, and having different types for each, you pretty much guarantee that all standard functions will operate on all 3 types of path, so you don't gain any security that way, since mistakes will still slip through. How about adding something like "restrictFilePaths :: FilePath -> IO ()" which will restrict the area that can be played with to that beneath the given FilePath?
I want to make sure a filename is valid. For example, "prn" and "con" are not valid path elements for normal files on Windows, certain characters are not allowed in filenames (depending on platform), some platforms may require paths to be escaped in different ways. I see there is a "isValid" function and even a (magical) "makeValid" function, but they do not report what was wrong with the filename in the first place. Furthermore, it isn't clear from the documentation how these functions determine whether a filename is valid. I don't check for prn and con, and I'm not sure if I should do. prn and con are files, they just happen to be special - you can still write to con for example. Maybe an isSpecial is more appropriate. The basic idea of the check is that it can't contain invalid character, for example ? in Windows. The motivation behind this is that programs such as Wget often dump their url to disk using the filename bit - and on windows this never works for urls with a ? at the end.
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. Yes, I hope almost everyone will ignore these functions. I can't think of many good reasons for playing with the drive, but as a FilePath
What isValid does is replace these "bad" characters with underscores. I guess its perfectly reasonable to get some information on why a filepath is invalid, so I'll add that. library its absolutely critical that the underlying functions all know intimately about drives and are safe with respect to them. Because of that there have to be these drive functions in the library, so I might as well export them. If someone uses them then good for them, but otherwise people can safely ignore them. Thanks Neil