Packages in GHC 6.6

[Bulat Ziganshin]

Hello Simon,

Wednesday, August 23, 2006, 2:26:56 PM, you wrote:

> Just replacing GHC without upgrading libraries (or RTS) should be possible

imho this is not very useful. typically, bug fixes are spread over
compiler, rts and libraries, so upgrading only compiler seems very
strange idea and upgrading to major new version (6.4.2->6.6)
will be impossible anyway

> If the base package is upgraded without also replacing the other libraries...
> this is where it gets really tricky.  Binary dependencies between library code
> tend to be very deep due to cross-module inlining and optimisations, so right
> now the chances of upgrading base without replacing everything else are almost
> zero.  To be able to do this I believe we have to track very carefully the
> API/ABI that a package is exposing, so that we can be sure that a replacement is
> truly compatible.  This may mean restricting optimisations across package
> boundaries.

i think that better way is to supply non-core libs in source form and
just recompile them in this case. so, eventually windows installation
should become equivalent of installing core ghc and then
downloading/compiling all the bundled libs. the benefit of packaging
these libs together with core ghc should be just that some "standard
library" exists and automatically downloaded with any windows ghc
installation. in all other ways these libs should be no different from
"non-standard" ones

for package-based unixes i propose making packages for all libs that
was considered "standard" as requirement to consider GHC port to this
OS as complete

so, GHC developers will not be bothered (at least, in theory :D) with
libraries distribution/support/upgrading problems, but nevertheless we
will retain some "standard libraries" set, which is supposed to be
supported by many OS/compiler combinations

as a consequence from this idea, non-core libs should be installed in
source form and then compiled by usual cabal procedure. on the
installation of new ghc version existing libs should be recompiled for
new ghc version. or alternatively, ghc should compile each library
when it first time used (with this ghc installation), like jhc does

ability to make at least minor ghc upgrades without recompiling
libraries installed (major upgrades are definitely impossible because
of .hi format changes) seems great but means that we can't inline
even 'head' definition outside of 'base' lib :)


-- 
Best regards,
 Bulat                            mailto:Bulat.Ziganshin at gmail.com