Generalise Package Support

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.

1 files changed, 13 insertions, 13 deletions

diff --git a/compiler/codeGen/CgCon.lhs b/compiler/codeGen/CgCon.lhs
index 0d8d731029..115439a0fd 100644
--- a/compiler/codeGen/CgCon.lhs
+++ b/compiler/codeGen/CgCon.lhs
@@ -70,10 +70,10 @@ cgTopRhsCon :: Id		-- Name of thing bound to this RHS
 	    -> FCode (Id, CgIdInfo)
 cgTopRhsCon id con args
   = do { 
-	; hmods <- getHomeModules
+	; this_pkg <- getThisPackage
 #if mingw32_TARGET_OS
         -- Windows DLLs have a problem with static cross-DLL refs.
-        ; ASSERT( not (isDllConApp hmods con args) ) return ()
+        ; ASSERT( not (isDllConApp this_pkg con args) ) return ()
 #endif
 	; ASSERT( args `lengthIs` dataConRepArity con ) return ()
 
@@ -83,9 +83,9 @@ cgTopRhsCon id con args
 	; let
 	    name          = idName id
 	    lf_info	  = mkConLFInfo con
-    	    closure_label = mkClosureLabel hmods name
+    	    closure_label = mkClosureLabel this_pkg name
 	    caffy         = any stgArgHasCafRefs args
-	    (closure_info, amodes_w_offsets) = layOutStaticConstr hmods con amodes
+	    (closure_info, amodes_w_offsets) = layOutStaticConstr this_pkg con amodes
 	    closure_rep = mkStaticClosureFields
 	    		     closure_info
 	    		     dontCareCCS		-- Because it's static data
@@ -142,9 +142,9 @@ at all.
 
 \begin{code}
 buildDynCon binder cc con []
-  = do hmods <- getHomeModules
+  = do this_pkg <- getThisPackage
        returnFC (stableIdInfo binder
-			   (mkLblExpr (mkClosureLabel hmods (dataConName con)))
+			   (mkLblExpr (mkClosureLabel this_pkg (dataConName con)))
     			   (mkConLFInfo con))
 \end{code}
 
@@ -198,9 +198,9 @@ Now the general case.
 \begin{code}
 buildDynCon binder ccs con args
   = do	{ 
-	; hmods <- getHomeModules
+	; this_pkg <- getThisPackage
 	; let
-	    (closure_info, amodes_w_offsets) = layOutDynConstr hmods con args
+	    (closure_info, amodes_w_offsets) = layOutDynConstr this_pkg con args
 
 	; hp_off <- allocDynClosure closure_info use_cc blame_cc amodes_w_offsets
  	; returnFC (heapIdInfo binder hp_off lf_info) }
@@ -230,10 +230,10 @@ found a $con$.
 \begin{code}
 bindConArgs :: DataCon -> [Id] -> Code
 bindConArgs con args
-  = do hmods <- getHomeModules
+  = do this_pkg <- getThisPackage
        let
 	  bind_arg (arg, offset) = bindNewToNode arg offset (mkLFArgument arg)
-	  (_, args_w_offsets)    = layOutDynConstr hmods con (addIdReps args)
+	  (_, args_w_offsets)    = layOutDynConstr this_pkg con (addIdReps args)
 	--
        ASSERT(not (isUnboxedTupleCon con)) return ()
        mapCs bind_arg args_w_offsets
@@ -416,7 +416,7 @@ static closure, for a constructor.
 cgDataCon :: DataCon -> Code
 cgDataCon data_con
   = do	{     -- Don't need any dynamic closure code for zero-arity constructors
-	  hmods <- getHomeModules
+	  this_pkg <- getThisPackage
 
 	; let
 	    -- To allow the debuggers, interpreters, etc to cope with
@@ -424,10 +424,10 @@ cgDataCon data_con
 	    -- time), we take care that info-table contains the
 	    -- information we need.
 	    (static_cl_info, _) = 
-		layOutStaticConstr hmods data_con arg_reps
+		layOutStaticConstr this_pkg data_con arg_reps
 
 	    (dyn_cl_info, arg_things) = 
-		layOutDynConstr    hmods data_con arg_reps
+		layOutDynConstr    this_pkg data_con arg_reps
 
 	    emit_info cl_info ticky_code
 		= do { code_blks <- getCgStmts the_code