base libraries

[Neil Mitchell]

Hi

> it's no more future than inclusion of module in Base lib.

It would be nice if your library splitting thing did happen so,
although my feeling is that it probably won't happen as fast as you
might hope, its quite a big change.

> we can
> discuss this just now and if GHC HQ will decline such proposal, i will
> agree that it may be better to include FilePath module in Cabal lib

I think base is a much better place to put a library than Cabal. (as
dcoutts said while I was writing this message)

> so your argument for inclusion it into the Base is to have *two*
> modules here with overlapping functionality? :)  someone who will does
> this optimization task may follow the same recommendations and move
> existing System.Directory modules into the FilePath lib. anyway, it
> will be better because it guarantees to not introduce
> backward-incompatible changes in non-upgradeable Base lib

I'm not 100% convinced the current System.Directory modules are
correct, I haven't examined them in enough detail, but experience
suggests that writing a FilePath library without QuickCheck and
without the Windows spec on what a drive/share looks like in front of
you will introduce corner cases.


> and, while you can't imagine progress of FilePath module, i can do.
> what you propose to do in this case - have two filepath modules, one
> in the base and one in other place? or make incompatible changes in Base?
> to be concrete, i want to make these functions polymorphic and be able
> to work on various string-alikes

type FilePath = String

I would hope that when/if we ever replace FilePath with a
string-a-like or ADT, we might want to rename the type at the same
time.

> experience shows that even such well-established modules as Data.List
> are sometimes changed. so, while your work is great, this don't mean
> that it will be frozen and can't be replaced with something even
> better

It can, but I suspect the better thing wouldn't manipulate FilePath's,
but general URL's or something with the file:// protocol as just a
special case.

We will never achieve perfection, but at some point we have to commit
to providing something with a fixed API that people can use. Having
things in a set of libraries which are tightly controlled is a good
idea - currently as my libraries stand, I can change the functionality
to reverse all the strings on the way out as I choose - hopefully if I
did that to a base library someone would stop me.

Thanks

Neil