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