Mon Sep 18 16:48:32 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
  * GADT selector bugfix, bits of cleanup
  Sun Aug  6 19:43:47 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
    * GADT selector bugfix, bits of cleanup
    Thu Jul 27 08:10:58 EDT 2006  kevind@bu.edu

Mon Sep 18 16:47:22 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
  * fix some GADT record selector bugs (still some remaining)
  Sun Aug  6 19:42:50 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
    * fix some GADT record selector bugs (still some remaining)
    Thu Jul 27 07:04:29 EDT 2006  kevind@bu.edu

Fixes ffi011(opt) on x86_64.  I don't know why this has only just
appeared today, it's apparently been broken for some time.

This is mainly to restore the old behaviour, but also we shouldn't
normally need the package name in a cost centre because only the
"main" package normally has cost centres.

This patch pushes through one fundamental change: a module is now
identified by the pair of its package and module name, whereas
previously it was identified by its module name alone.  This means
that now a program can contain multiple modules with the same name, as
long as they belong to different packages.

This is a language change - the Haskell report says nothing about
packages, but it is now necessary to understand packages in order to
understand GHC's module system.  For example, a type T from module M
in package P is different from a type T from module M in package Q.
Previously this wasn't an issue because there could only be a single
module M in the program.

The "module restriction" on combining packages has therefore been
lifted, and a program can contain multiple versions of the same
package.

Note that none of the proposed syntax changes have yet been
implemented, but the architecture is geared towards supporting import
declarations qualified by package name, and that is probably the next
step.

It is now necessary to specify the package name when compiling a
package, using the -package-name flag (which has been un-deprecated).
Fortunately Cabal still uses -package-name.

Certain packages are "wired in".  Currently the wired-in packages are:
base, haskell98, template-haskell and rts, and are always referred to
by these versionless names.  Other packages are referred to with full
package IDs (eg. "network-1.0").  This is because the compiler needs
to refer to entities in the wired-in packages, and we didn't want to
bake the version of these packages into the comiler.  It's conceivable
that someone might want to upgrade the base package independently of
GHC.

Internal changes:

  - There are two module-related types:

        ModuleName      just a FastString, the name of a module
        Module          a pair of a PackageId and ModuleName

    A mapping from ModuleName can be a UniqFM, but a mapping from Module
    must be a FiniteMap (we provide it as ModuleEnv).

  - The "HomeModules" type that was passed around the compiler is now
    gone, replaced in most cases by the current package name which is
    contained in DynFlags.  We can tell whether a Module comes from the
    current package by comparing its package name against the current
    package.

  - While I was here, I changed PrintUnqual to be a little more useful:
    it now returns the ModuleName that the identifier should be qualified
    with according to the current scope, rather than its original
    module.  Also, PrintUnqual tells whether to qualify module names with
    package names (currently unused).

Docs to follow.

static relative offsets (eg .long l1-l2) are restricted to 32 bits on
x86-64 due to lack of support in the linker.  The codegen, NCG and
runtime work around this, using 32-bit offsets instead of 64.
However, we were missing a workaround for vector tables, and it
happened to work by accident because the offsets were always positive
and resolved by the assembler.  The bug was exposed by using the NCG
to compile the RTS, where the offsets became negative, again by
accident.

Most of the other users of the fptools build system have migrated to
Cabal, and with the move to darcs we can now flatten the source tree
without losing history, so here goes.

The main change is that the ghc/ subdir is gone, and most of what it
contained is now at the top level.  The build system now makes no
pretense at being multi-project, it is just the GHC build system.

No doubt this will break many things, and there will be a period of
instability while we fix the dependencies.  A straightforward build
should work, but I haven't yet fixed binary/source distributions.
Changes to the Building Guide will follow, too.