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