-- 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:[EMAIL PROTECTED] _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
