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