Adding System.FilePath

[Bulat Ziganshin]

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