
On Wed, Oct 27, 2004 at 12:47:24AM -0700, Krasimir Angelov wrote:
--- Andrew Pimlott
wrote: Well, for example you couldn't write a file picker with this API, because you can't ask for all the roots. Maybe that's enough, because pathInits can be used to find the root for a given file (the first element of pathInits being the root).
The pathInits isn't suitable in this case. It is useful in case if you want to create some file but you are not sure wheter all directories in the path are created. The pathInits returns a list of all directories that must must be created. Some examples:
pathInits "c:" == [] pathInits "c:\\" == [] pathInits "c:\\dir1" == ["c:\\dir1\\"] pathInits "c:\\dir1\\dir2" == ["c:\\dir1\\", "c:\\dir1\\dir2"]
This is an example of why I find this library so unsatisfactory: Effectively, the only way to use this function is to know the specific purpose for which it was written. There's no model I can keep in my head to make sense of it. Even if you document it, I suspect it will confuse people. (In my case, when I saw this function, I immediately assumed it would return all parent directories, so I could eg search upward for a file.) If you really want it, call it parentDirectoriesYouMightNeedToCreateBeforeCreatingThisFile. ;-) I realize you're just collecting existing functions, and that they have all proven useful for some task, but that doesn't necessarily make a useful general-purpose library.
For example, what should splitFileName "/" (unix) or splitFileName "." be, and why? I can't think of any answers that are consistent with the type (FilePath -> (String, String)).
In the current implementation: splitFileName "/" == ("/", "")
What does an empty filename mean?
splitFileName "." == (".", ".")
This again runs contrary to my intuition: I expect to get back the parent, and the name of the file relative to the parent. All these weird cases make the library hard to use without reading the code, going by trial and error, or reading the documentation (assuming it is scrupulously complete) _very_ carefully. (Which, as I complained in the old message I cited, also the case with every other path API I've used.) Andrew