System.FilePath propsal (Was: Cabal feedback notes)
Graham Klyne
gk at ninebynine.org
Thu Oct 28 08:43:58 EDT 2004
Krasimir,
Thanks for your work on this, and your responses...
At 13:05 27/10/04 -0700, Krasimir Angelov wrote:
>--- Graham Klyne <GK at ninebynine.org> wrote:
> > 1. How are multiple extensions handled? (e.g.
> > foo.tar.gz) I think this is
> > catered for, with the final extension being picked
> > off.
>
>splitFileExt always return the last extension.
Sounds good to me.
> > 2. How does path joining work in this case:
> >
> > joinPaths C:/root/path/file.ext
> > altPath/file2.ext2
> >
> > i.e. is "file.ext" discarded?
>
>No. You will get:
>
>C:/root/path/file.ext/altPath/file2.ext2
Hmmm. I can't claim it's wrong, but I'm uneasy about that. It is, for
example, different from the way that URI path joining works.
What about:
joinPaths C:/root/path/ altPath/file2.ext2
does this give:
C:/root/path/altPath/file2.ext2
or
C:/root/path//altPath/file2.ext2
?
> > 3. What is the purpose of commonInit?
>
>commonInit is renamed to commonParent in the last
>version. It returns the largest path that is common in
>all paths in the list.
Ah, I see.
> > Also, a very small point: I forgot that FilePath is
> > defined in the
> > prelude... maybe a comment to this effect on the
> > module export list?
>
>I will add FilePath to the export list (Simon's
>suggestion).
With a comment that it is defined in the Prelude?
> > I'm rather taken by the approach that Peter Simons
> > suggests [1]
> > (abstracting the path composition), but I suspect
> > there are more details to
> > be worked out there. It also makes my earlier
> > suggestion [2] of using a
> > URI-based representation as a common abstraction
> > seem slightly less
> > radical. I also note Simon's comments on this
> > (don't do it yet_) are
> > persuasive. I'll reserve my campaign to unify
> > filenames and URIs for the
> > "ultimate" FilePath abstraction ;-)
>
>It could be great to have filePathToURI and
>uriToFilePath functions in Network.URI. There we can
>also have URI manipulation functions but this doesn't
>mean that we don't need have System.FilePath in
>addition.
I've been toying with ideas for creating scheme-specific URI functions in
sub-modules, e.g.
Network.URI.http
Network.URI.file
etc.
When the IETF decides what to do about the revised file: URI specification,
I might give this a try, lifting some code I wrote for XML processing.
#g
------------
Graham Klyne
For email:
http://www.ninebynine.org/#Contact
More information about the Libraries
mailing list