Bulat Ziganshin wrote:
Hello Henning,
Tuesday, January 29, 2008, 9:54:18 PM, you wrote:
The question is - where to add it, if not to Data.List? We could setup new Data.List.Extras. But this would have the same problem like Data.List. Is the solution to move Data.List from 'base' to 'containers' or so, since the basic list functions are already in Prelude?
the whole problem is that base is hard-wired with ghc and CAN'T BE UPGRADED. so i propose to add new package for all those new funcs and freeze base to solve problem of ghc versions incompatibility
Freezing base is a bad idea. - we'd end up with silly packages called things like 'listexts' with Data.List.Exts. - we have no way of evolving the design of the libraries, no way to make improvements. We're stuck with a design which is widely acknowledged to be lacking in various serious ways (e.g. no Unicode in the IO library). What we propose to do instead is to provide better support for backwards compatibility. I'm honestly not sure whether this will lead to more problems, or whether it will just work nicely, but it's pretty clear we have to try. Before responding, take a good read through http://hackage.haskell.org/trac/ghc/wiki/PackageCompatibility In particular, I think the most practical approach is 4.3, although this doesn't give complete backwards compatibility. If you have a better suggestion, let's hear it - but please nothing of the form "oh, it must be possible to just do X", think about all the ramifications of "just doing X" and add a proposal to the wiki page, or write a new page. In addition to this, we need to get packages using the Package Versioning Policy: http://haskell.org/haskellwiki/Package_versioning_policy For this we need support in Cabal and/or Hackage. By the time we release GHC 6.10, we want most packages in Hackage using accurate dependencies, so that the majority will continue to work with GHC 6.10. Something else we have to think about is upgrades. We're now commonly seeing multiple versions of packages installed, leading to problems when resolving dependencies ends up with two different versions of a given package, and type errors ensue. It's probably time to start a new wiki page for thinking about solutions to this. Cheers, Simon