System.FilePath propsal (Was: Cabal feedback notes)

[Krasimir Angelov]

--- Andrew Pimlott <andrew at pimlott.net> wrote:
> > 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.
> ;-)

Another way is to assume the following rules for
pathParents (pathInits is renamed to pathParents in
the last version):

pathParents "/foo/bar" == ["/","/foo","/foo/bar"]
pathParents "foo/bar"  == [".","/foo","/foo/bar"]

Note that for local paths the first element in the
list is ".". This allows us to easily get the original
behaviour:

oldPathParents = tail . pathParents

This looks more useful. You can easily search
upward for a file. :-)

> > In the current implementation:
> > splitFileName "/" == ("/", "")
> 
> What does an empty filename mean?

There already was suggested that in this case the
result must be ("/", ".") but I am not sure whether
this is right because in this case we really don't
have any file name.

> > 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.  

These are exactly the names of parent and the name of
file. This is exactly "./." which is equivalent to
".". Actualy:

"." `joinFileName` "." == "."

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
> 

Suggestions for improvements are always wellcome.

Cheers,
  Krasimir




		
__________________________________
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.
http://promotions.yahoo.com/new_mail