Hello Simon, Thursday, January 31, 2008, 2:15:58 PM, you wrote:
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).
"Freezing base is a bad idea" only in the situation when we fear to duplicate any code. but really this leads to situation when the same code needs to be duplicated in every serious program, starting from GHC itself! why i have Utils module with dozens of list funcs? why you duplicated in GHC bag, bitset, encoding support, finite maps and lots of other standard code? i propose to freeze base in its current state and duplicate everything we want to evolve to separate libs. want to evolve i/o libs? no problem - just copy system.io to new.system.io and add anything you want. this new implementation will be outside of base so everyone will be able to use just the version he need at last end, "old good things" in base will remain only for backward compatibility with "old good books" like haskell98 package now used and as a base for other libraries, like GHC.* modules now used we shouldn't take new code into the base library because this only makes problem harder. are you not consider as a problem that it's impossible to develop code which will work with different ghc versions? in particular, i think we *have* library which supports unicode. it's not mature enough but it's better to evolve this lib or write another one which will be independent of base instead of making any changes to existing 2kloc Handle implementation
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
first, now it is clear how to handle situation in 6.8 - with 4.2 we will have no more problems than with previous ghc upgrades
"Each time we split base we have to invent a new name for it, and we accumulate a new compatibility wrapper for the old one."
not true. for previous base versions, we never declared that it obeys HLP (haskell libraries policy), so users was absolutely right using general "base" dependency. for newbase library we will need to declare this and require that user specify "newbase 1.*" dependency, so newbase 2.0+ can make any API changes my proposal of freezing the base is exactly what i propose to do in order to finally solve "base problem". the proposed solution seems unusual for the first look but it really works and really solves the problem for 100%. actually, it's much better than duplicating code in every application program. the main disadvantage of duplicated code - maintenance costs - will be probably zero in this case because existing code in base rarely need to be fixed
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.
a few days ago i've released first version of my GUI program. it had support for 69 localizations. how it was done? i just wrote script which translated language files of another program with close functionality :) we have only two ways to make all hackage libs compatible with 6.10 - either make *ghc* compatible with existing libs or *convert* these libs to the new format. but forcing authors to upgrade their libs is a bad idea. now i have feeling that goals of ghc/cabal/hackage developers isn't to provide eternal compatibility but to research various ways of providing such compatibility and write interesting papers about user reaction to all their experiments. sorry, but it is what i see
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.
sure. one idea we can import from my proposal is to recommend users to write their code against some "gem" of libraries - HSL-2008, HSL-2009... -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com