Hello Artem, Friday, March 16, 2007, 12:09:49 PM, you wrote:
Unlike a lot of other languages (like Java) which grow incrementally, heaving the whole lot of old baggage in their library API, GHC base is allowed to evolve its interfaces (and yes, that breaks compatibility). I think it is a healthy approach, while the Java approach might bloat it to death (sadly, as i'm a Java user; at least the bytecode seem remains in good shape). Sorry if it seem like offtopic, but i think the ability of GHC base to evolve, instead of just bloating away, is vital.
this creates problems for developers and users. for example, program developed 3 years ago, may be easily incompatible with current ghc version instead, i propose to keep evolving things outside of base, which will allow to use any version of any library with any ghc version. if you build something written in times of ghc 6.2 - you use old version of library. if you build something more modern - you use newer version. cabal automatically handles keeping of multiple versions of same library and using proper version for each build. this technology provides us *both* evolving of libraries and compatibility with old versions -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com