Hello Duncan, Friday, March 16, 2007, 4:58:08 PM, you wrote:
So some of these are just bug fixes and not api changes so will be in 6.6.1.
and some will be deferred until 6.8 when we will have one more incompatibility-break? thank you
The changes are really pretty minor and only in the very low level part of the api.
but these parts are used too, yes? and libraries which depend on these features will be not compatible across ghc versions
But in general: so you could say that these bugs show we should have waited longer for the library to mature, on the other hand I rather suspect that we'd never have found these without the huge number of people using the lib that came from it being included as standard.
there are no differences in this aspect between base and any other bundled library
Bulat, I'm not arguing against making base a bit more modular, but you know how hard a task that is.
yes, and i tell about detaching part of base that still don;t have circular dependencies while you are planning to add such dependencies and make it undetachable. imho, FPS team work is very interesting in technical part, but not so good in social part. we can't work with newer implementations of your lib. we can't ask for new features to add (i mean that these features anyway will not be available for 6.6). you consider base as your own property and don't take into account other people requirements. if fps will be detached from base, i can develop my own libraries based on particular fps version and they will work with any ghc compiler. if your great idea about fast readFile implementation will be implemented via low-level IO lib as i proposed, this means that i can extend it to support unicode filenames and it will work with any ghc version, again
oh my god! you plan to further evolve base library and its legacy i/o part. but how about using unicode filenames or newer async i/o api? it should be also implemented inside base? one library for anything? :)
It's quite independent. It could work with any standard IO system. I mention the H98 readFile etc because that's what we have right now.
Note that one could take advantage of async IO without changing the Handle API.
and to implement this, one should change base, again. so the problem of monolithic base grows and grows. your better *technical* implementation of readFile as part of base raises number of *social* problems (i mean problems with unavailability of changes in base until ghc release, lack of support for alternative designs, incompatible changes of base between ghc versions) if, instead, you will implement new readFile as part of separate i/o package, it will be immediately available and support movement toward smaller building blocks
i think that it will be much better if fps will be detached from base and you will provide i/o library on top of fps and lowIO [1] that makes all these cool things. this way you will got support of all the features lowIO provides for free
As I said, it's quite independent. You could use ByteStrings with any sane IO library since all it needs is to be able to read/write data buffers.
but you can't use lowIO library inside base and this means that in order to support unicode filenames in base.readFile one need to implement their support inside of base. so, your force further growing of base instead of making many small separate packages -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com