Adding System.FilePath

Duncan Coutts duncan.coutts at worc.ox.ac.uk
Thu Mar 15 18:44:26 EDT 2007


On Thu, 2007-03-15 at 23:25 +0300, Bulat Ziganshin wrote:

> the beauty of this proposal is that we can issue 3rd, 4th and any
> other version based on real users feedback. including some module into
> base means stopping of its active development, you can see the
> situation with ByteString

You keep saying this but I really do not think it is true.

There's nothing stopping people from adding new ByteString style
functions. We export all the internals to make that possible. For
example you'll notice that people have been looking at Unicode stuff,
binary encoding, compression etc. There's been no lack of progress.

We're not changing the main exported api because it already matches the
Data.List api which was the original intention. That does not stop you
from making extensions and exporting them from different modules.

We're also planning to replace the current ByteString implementation
with the version described in our paper that does the stream fusion
rather than the older style functional array fusion. We can change this
in base any time since it does not break any external APIs. We probably
will not get around to doing that before 6.6.1 since we're working on
other things at the moment but the point is that we could.

You say that things added to base never change, have you considered that
this might be because things get added to base when they are mature
rather than because adding things to base imposes a code freeze?

Of course if a module is still maturing and in a state of flux then
adding it to base wouldn't be a good idea as one could not promise API
stability. System.FilePath doesn't seem to be in that situation however,
in my opinion it's ok to go into base (and come out again if/when base
gets split up).

Duncan



More information about the Libraries mailing list