System.FilePath Re[2]: ANN: HSH 1.2.0

Neil Mitchell ndmitchell at
Tue Mar 13 05:24:42 EDT 2007

Hi Bulat,

> >> I note that the deadline for discussion of System.FilePath has now passed (well,
> >> a long time ago :-), so it looks like it's going into base.  Any final
> >> objections before we do this?
> > The deadline passed before Christmas, and no one objected. I still
> > intend to move it in to base,
> may be it is a good time to start File library? i has some ideas for
> it, and also want to propose it as SoC project. just a couple of
> ideas:
> - ghc rts independent i/o lib
> - portable async i/o which is able to work via select/epoll/...
> - support for unicode filenames
> - String/ByteString/UTF8String as filename
> - filepath operations (your module)
> - filesystem operations (System.Directory)
> - support for large files (>4gb) on windows
> - bytestring i/o
> - interfacing with Streams and FPS libraries

These are all worth thing to do, but there are two different type of
operations here - those that operate on filenames, and those that do
IO. As Simon Marlow has previously said,  keeping these things
separate is usually a good idea.

This also seems to be an attempt to replace type FileName = -
something that is going to take much more work.

Rolling my FilePath code into this package is perfectly fine, but I
think the FilePath operations specialised to String (as defined by
Haskell 98) are important to go into base, if for no other reason than
without them Cabal cannot depend on them.

I realise you are trying to split up the base library, but Cabal
requires it keep to be kept intact just a little bit longer ;)



More information about the Libraries mailing list