System.FilePath propsal (Was: Cabal feedback notes)

[Andrew Pimlott]

On Wed, Oct 27, 2004 at 12:47:24AM -0700, Krasimir Angelov wrote:
> 
> --- Andrew Pimlott <andrew at pimlott.net> 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