-- 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@gmail.com

Hello Bryan, Saturday, March 10, 2007, 8:19:37 PM, you wrote:

...

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

strange, but your letter don't contains crossposts to them. may be it's because i had errors when tried to add crossposting to them. well, i continue in the libraries list

...

- portable async i/o which is able to work via select/epoll/... I think you mean non-blocking I/O here, right? Async is not the same thing.

i don't mentioned all the features that are already in ghc i/o library, they are just too numerous. but of course i suppose that we want to support them all. non-blocking i/o is among these things (see hGetBufNonBlocking/hPutBufNonBlocking) async i/o is idea of SimonM/JohnM/Einar of adding support of epoll and other async i/o systems so that thousands of haskell threads may perform i/o simultaneously w/o much cpu overhead. btw, it's already implemented in network-alt lib, but only for its networking i/o facilities. John Meacham issued an idea of universal API on top of all these systems that may be used by any i/o library (and haskell compiler) to easily implement support for async i/o. but we need details, unix tricks is not my area of knowledge

...

- interfacing with Streams and FPS libraries

It should also integrate cleanly with the network stack, which needs an overhaul about as badly as the I/O library. Einar Karttunen maintains his network-alt library at http://www.cs.helsinki.fi/u/ekarttun/network-alt/ which I think is a good starting point.

yes, it's one more topic that i lost (and what i don't understand like i don't understand unix) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

Hello Donald, Sunday, March 11, 2007, 4:32:54 AM, you wrote:

...

...

...

- portable async i/o which is able to work via select/epoll/...

You probably should look at the unified events library as well:

http://www.seas.upenn.edu/~lipeng/homepage/unify.html

i've seen such libs and even downloaded them but anyway i don't know this area so someone else should make a design -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

Hello Neil, Tuesday, March 13, 2007, 12:24:42 PM, you wrote:

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.

i don't see it that way. for me, there are plenty of APIs which are sitting on top of each other: * operations on String/ByteString/... * class Stringable which provides uniform access to these operations * FilePath module which operates on filenames represented in any Stringable form * Directory module which works with filesystem using FilePath operations * File i/o routines where open() uses Stringable again and so on what i propose is to detach middle layer (from FilePath to File i/o) of this stack into one library. splitting may be different, the main reason to propose this one is because there are at least 2 different approaches to make buffering (Streams and SSC), but both should be happy working via such low-leve i/o lib. we can also split this functionality (FilePath, Directory, File, MappedFile) further to 2-4 libs, but i don't have any concrete reasons to propose it i'm definitely against merging FilePath into base because this means that it will be not available for applications until 6.8 arrives, and make impossible to improve it without losing backward compatibility. i've written about these problems in context of FPS library. now there are updated versions of this lib that can't be used with 6.6 and therefore lost for potential users. because i need improved version of your module (with support for UTF8String), i definitely against inclusion it into the base

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

the beauty of idea is that you can roll out now FilePath 1.0 with just a String support and when Stringabe support will be implemented, it will become FilePath 2.0 release. It's impossible with Base because there are no ways to distinguish between various versions of it nor there is compiler-independent version evolution

Rolling my FilePath code into this package is perfectly fine, but I think the FilePath operations specialised to String (as defined by Haskell 98)

and what? H98 libs are useless in real world

are important to go into base, if for no other reason than without them Cabal cannot depend on them.

but we don't need to add operations required for Cabal into the base. let's clarify. if Base is library for Cabal, then we should keep here Cabal-specific things. if it's the library for users, then we should make other decisions. i think that we need to have CabalLib, installed with any haskell compiler, which should contain any features required by Cabal. or even simpler, your compiler-independent code may be included in Cabal itself and dead there without further changes But for *people* we need upcoming versions of your module and this requirement is very different from that is required for Cabal. although just for this moment including FilePath into Base and using it both by people and Cabal seems to be fine solution, in long term this is just one more bomb for Haskell libs progress

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

i can't agree. all that Cabal requires is to import compiler/os-specific functionality from preinstalled libs. but preinstalled/=Base and moreover your functionality isn't *-specific -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

Hi

No, Cabal requires that things needed by Setup.*hs files (such as the FilePath module) come with all compilers. That can be done by shipping the filepath package with all compilers rather than putting the module into the base package.

When last speaking to Duncan he gave me the impression that Setup.hs can only depend on base. If this is not the case, and we have a procedure for "making this a library that comes with absolutely every compiler", then I'm happy to create it as a filepath library, provided: * There are no circumstances under which import Data.List will work, but import System.FilePath will not i.e. on parity with the base libraries. Does such a place/package exist? Thanks Neil

Hi

"runhaskell", "ghc --make" and hugs would all work.

"ghc -package base -package Cabal" wouldn't, but I doubt that will trip anyone up given it won't be in any docs (and so anyone it does trip up probably knows how to fix it anyway).

Cabal users will have to explicitly depend on FilePath though, i.e. all users of Cabal will need to know that System.FilePath isn't in the base, it is in a separate module.

...

i.e. on parity with the base libraries. Does such a place/package exist?

You just have to convince each implementation separately to ship with it.

But if its a case of each implementation defining their own policy, then suddenly you can't use it in Cabal Setup.hs files. Thanks Neil

On Wed, 2007-03-14 at 01:22 +0000, Ian Lynagh wrote:

On Wed, Mar 14, 2007 at 01:06:10AM +0000, Neil Mitchell wrote:

...

...

"runhaskell", "ghc --make" and hugs would all work.

"ghc -package base -package Cabal" wouldn't, but I doubt that will trip anyone up given it won't be in any docs (and so anyone it does trip up probably knows how to fix it anyway).

Cabal users will have to explicitly depend on FilePath though, i.e.

No they won't: If Setup.hs builds then it's installed, and besides, we don't need it any more if we've already built Setup. So there's no point in Setup.hs checking it's installed (which is the effect of adding a dep in the .cabal file, which I assume is what you meant).

There was this idea that cabal-setup should compile Setup.hs using only a limited set of packages exposed. This is to stop unfortunate QA issues where a developer makes a Setup.hs module that builds on his machine but not on a users machine because they're missing some package. So yes, cabal-setup would only let you import things from base and whatever set of other core packages we can agree on. Duncan

On Wed, Mar 14, 2007 at 01:39:18AM +0000, Neil Mitchell wrote:

Hi

...

No they won't: If Setup.hs builds then it's installed, and besides, we don't need it any more if we've already built Setup. So there's no point in Setup.hs checking it's installed (which is the effect of adding a dep in the .cabal file, which I assume is what you meant).

I see your point, but Cabal passes -package base etc, so even if FilePath is installed, its not visible to a Cabal compiled program by default.

If by Cabal you mean "./Setup build" then yes, it passes -package base etc for the build-deps, but if I understand correctly you are talking about /compiling/ Setup. You are right that cabal-setup would need to pass -package foo, but that's just something we do and users don't need to worry about. Thanks Ian