[[project @ 2002-01-30 17:19:15 by simonmar] simonmar**20020130171915 Add a short section on modules & packages. ] { addfile ./ghc/docs/comm/the-beast/modules.html hunk ./ghc/docs/comm/index.html 52 +

Modules, ModuleNames and Packages hunk ./ghc/docs/comm/the-beast/modules.html 1 + + + + + The GHC Commentary - Modules, ModuleNames and Packages + + + +

Modules, ModuleNames and Packages

+ +

This section describes the datatypes ModuleName + Module and PackageName all available + from the module Module.

+ +

Packages

+ +

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. + +

The ModuleName type

+ +

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. + +

The Module type

+ +

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. + + }