The module that GHCi uses for its default scope should be exactly
base:Prelude, not whatever Prelude is found on the search path.

This patch performs several optimizations with the goal of minimizing the cost of building the arguments to breakpointJump:
  - Group them all in a single tuple, to minimize closure creation in heap
  - Wrap this with the GHC.Base.lazy combinator, to induce max laziness
  - Remove as many literal strings as possible 
    * injecting a module-local CAF to store the module name and use that 
    * eliminating the package string (not needed).

By popular request, in a breakpoint it is possible now to inspect the result of the expression wrapped by the breakpoint.

The user interface for this is right now preliminar; there is a new binding called '_result' at every breakpoint. Suggestions are welcome!

Previously, when in a breakpoint, :quit was used to continue execution.
This is not the right thing to do, so this patch restores :quit to its
original meaning whether or not ghci is in an inferior session.

The continue behavior is now provided by ":breakpoint continue".
I added a synonim command in :continue because it is much shorter,
but this is optional

  pprTypeApp :: SDoc -> [Type] -> SDoc
  pprTypeApp pp tys = hang pp 2 (sep (map pprParendType tys))

Instrumentation gets activated by the '-fdebugging' dynflag.

All the instrumentation occurrs in the desugarer; it consists of inserting 'breakpoint' combinators at a number of places in the AST, namely: 
 - Binding sites
 - Do-notation statements 
These 'breakpoint' combinators will later be further desugared (at DsExpr) into ___Jump functions.
For more info about this and all the ghci.debugger see the page at the GHC wiki:

http://hackage.haskell.org/trac/ghc/wiki/GhciDebugger

The entry point is:
setBreakpointHandler :: Session -> BkptHandler Module -> IO ()

RtClosureInspect includes a bunch of stuff for playing with closures:

- the datatype Closure is the low level representation type
- the datatype Term is the high level representation type
- cvObtainTerm is the main entry point, providing the Term representation of an arbitrary closure

Tracked down by Krasimir Angelov

This large commit combines several interrelated changes:

  - IfaceSyn now contains actual Names rather than the special
    IfaceExtName type.  The binary interface file contains
    a symbol table of Names, where each entry is a (package,
    ModuleName, OccName) triple.  Names in the IfaceSyn point
    to entries in the symbol table.

    This reduces the size of interface files, which should
    hopefully improve performance (not measured yet).

    The toIfaceXXX functions now do not need to pass around
    a function from Name -> IfaceExtName, which makes that
    code simpler.

  - Names now do not point directly to their parents, and the
    nameParent operation has gone away.  It turned out to be hard to
    keep this information consistent in practice, and the parent info
    was only valid in some Names.  Instead we made the following
    changes:

    * ImportAvails contains a new field 
          imp_parent :: NameEnv AvailInfo
      which gives the family info for any Name in scope, and
      is used by the renamer when renaming export lists, amongst
      other things.  This info is thrown away after renaming.

    * The mi_ver_fn field of ModIface now maps to
      (OccName,Version) instead of just Version, where the
      OccName is the parent name.  This mapping is used when
      constructing the usage info for dependent modules.
      There may be entries in mi_ver_fn for things that are not in
      scope, whereas imp_parent only deals with in-scope things.

    * The md_exports field of ModDetails now contains
      [AvailInfo] rather than NameSet.  This gives us
      family info for the exported names of a module.

Also:

   - ifaceDeclSubBinders moved to IfaceSyn (seems like the
     right place for it).

   - heavily refactored renaming of import/export lists.

   - Unfortunately external core is now broken, as it relied on
     IfaceSyn.  It requires some attention.

Mon Sep 18 18:50:35 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
  * Extended TyCon and friends to represent family declarations
  Tue Aug 15 16:52:31 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
    * Extended TyCon and friends to represent family declarations

This cleans up the package subsystem a little.  There are some
changes to the GHC API as a result.

  - GHC.init and GHC.initFromArgs are no longer necessary.

  - GHC.newSession takes the root of the GHC tree as an argument
    (previously passed to GHC.init).

  - You *must* do GHC.setSessionDynFlags after GHC.newSession,
    this is what loads the package database.

  - Several global vars removed from SysTools

  - The :set command in GHCi can now cause new packages to be loaded,
    or can hide/ignore existing packages.

In particular, if we're searching for the profiling version of a
module in another package, then suggest that perhaps it might not have
been installed.

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.

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.

Use the lexer to parse OPTIONS, LANGUAGE and INCLUDE pragmas.
This gives us greater flexibility and far better error
messages. However, I had to make a few quirks:
  * The token parser is written manually since Happy doesn't
    like lexer errors (we need to extract options before the
    buffer is passed through 'cpp'). Still better than
    manually parsing a String, though.
  * The StringBuffer API has been extended so files can be
    read in blocks.
I also made a new field in ModSummary called ms_hspp_opts
which stores the updated DynFlags. Oh, and I took the liberty
of moving 'getImports' into HeaderInfo together with
'getOptions'.

This restructoring makes the renamed export and import lists
available in IDE mode.

This patch adds completion support to GHCi when readline is being
used.  Completion of identifiers (in scope only, but including
qualified identifiers) in expressions is provided.  Also, completion
of commands (:cmd), and special completion for certain commands
(eg. module names for the :module command) are also provided.