This section describes the datatypes ModuleName
+ Module and PackageName all available
+ from the module Module.
+ +
A package is a collection of (zero or more) Haskell modules, + together with some information about external libraries, extra C + compiler options, and other things that this collection of modules + requires. When using DLLs on windows (or shared libraries on a + Unix system; currently unsupported), a package can consist of only + a single shared library of Haskell code; the reason for this is + described below. + +
Packages are further described in the User's Guide here. + +
At the bottom of the hierarchy is a ModuleName,
+ which, as its name suggests, is simply the name of a module. It
+ is represented as a Z-encoded FastString, and is an instance of
+ Uniquable so we can build FiniteMaps
+ with ModuleNames as the keys.
+
+
A ModuleName can be built from a
+ String, using the mkModuleName function.
+
+
For a given module, the compiler also needs to know whether the + module is in the home package, or in another package. + This distinction is important for two reasons: + +
When generating code to call a function in another package, + the compiler might have to generate a cross-DLL call, which is + different from an intra-DLL call (hence the restriction that the + code in a package can only reside in a single DLL). + +
We avoid putting version information in an interface file + for entities defined in another package, on the grounds that other + packages are generally "stable". This also helps keep the size of + interface files down. +
The Module type contains a ModuleName
+ and a PackageInfo field. The
+ PackageInfo indicates whether the given
+ Module comes from the current package or from another
+ package.
+
+
To get the actual package in which a given module resides, you
+ have to read the interface file for that module, which contains
+ the package name (actually the value of the
+ -package-name flag when that module was built). This
+ information is currently unused inside the compiler, but we might
+ make use of it in the future, especially with the advent of
+ hierarchical modules, to allow the compiler to automatically
+ figure out which packages a program should be linked with, and
+ thus avoid the need to specify -package options on
+ the command line.
+
+
Modules are also instances of
+ Uniquable, and indeed the unique of a
+ Module is the same as the unique of the underlying
+ ModuleName.
+
+