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

Bulat Ziganshin bulat.ziganshin at gmail.com
Sat Mar 10 08:42:35 EST 2007


-- i've added crossposts to John Meacham and Einar Karttunen because
-- you also denoted interest in new i/o library

Hello Neil,

Friday, March 9, 2007, 9:12:31 PM, you wrote:

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

there are LOTS of things that need to be implemented in order to make
modern i/o library. your module seem as a first building block. we
can't make all these things inside Base lib because upgradability
problems will hit us all the way. so i propose to make File library
consisting of your sole module and start to wait contributions :) if
someone will need just the interface you already implemented, he can
request File-0.1 version - it will be again impossible if you will
integrate your library in the Base

as i many times said, Base is the dead end for any code, so it should
contain only things that will be not changed in next 5 years. i
know how your code may be changed in near future - by adding
ByteString support. moreover, i propose to "split" base library
without losing backward compatibility just by creating new libs that
will contain essentially the same code. i propose to start new i/o lib
with your module

>> Regarding canonicalizePath, I'd be perfectly happy to change its name and/or
>> somehow make it more easily discoverable: does anyone want to make a proposal?

> I recommend either changing the name to unportableGHCCanonicalizePath
> or implementing it for Hugs ;)

> I can't think of a good name, FilePath originally called it
> makePathAbsolute,

i like this name. it denotes action and that is right because it works
in IO monad, not a pure function. and it makes clear that it does,
while "canonical" may mean everything, just like "shuffle" or
"change'a'bit"


-- 
Best regards,
 Bulat                            mailto:Bulat.Ziganshin at gmail.com



More information about the Libraries mailing list