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