freezing the base

[Bulat Ziganshin]

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 at gmail.com