System.FilePath propsal (Was: Cabal feedback notes)

[Glynn Clements]

Andrew Pimlott wrote:

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

I don't see what other result is possible in this case. It can't
return the current directory as the first member without being in the
IO monad.

And in any case, that may not be what you want; there are reasons for
wanting to manipulate paths without reference to the current state of
the process or of the filesystem.

You may be dealing with paths which existed at some point in the past
(e.g. in a tar/zip/etc archive), or which will exist at some point in
the future (i.e. once you've started performing the installation
sequence which you're in the process of planning), or which exist (did
exist, will exist) on another system, but which don't exist here and
now.

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

It will probably be the case with every path API which you will ever
use. There are many difficult problems here.

Certainly, the predictive case ("what will be the effect of passing
this path to a given system call?") is undecidable on a multi-tasking
OS.

E.g. you can't reliably determine in advance where chdir("foo") will
take you. You have to execute the call then discover where you
actually ended up afterwards.

And this isn't just a theoretical problem; the bugtraq archives are
full of examples of exploiting race conditions between testing the
current state of the filesystem and making modifications based upon
those results.

-- 
Glynn Clements <glynn at gclements.plus.com>