• Simon Marlow's avatar
    Generalise Package Support · 61d2625a
    Simon Marlow authored
    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.
    61d2625a
TcRnMonad.lhs 32.7 KB