From 6920123095e8a30f6f09d982db1e746376f73f87 Mon Sep 17 00:00:00 2001 From: simonmar Date: Wed, 30 Jan 2002 17:19:15 +0000 Subject: [PATCH] [project @ 2002-01-30 17:19:15 by simonmar] Add a short section on modules & packages. --- ghc/docs/comm/index.html | 1 + ghc/docs/comm/the-beast/modules.html | 80 ++++++++++++++++++++++++++++++++++ 2 files changed, 81 insertions(+) create mode 100644 ghc/docs/comm/the-beast/modules.html diff --git a/ghc/docs/comm/index.html b/ghc/docs/comm/index.html index 542406b..dd381c9 100644 --- a/ghc/docs/comm/index.html +++ b/ghc/docs/comm/index.html @@ -49,6 +49,7 @@

Sugar Free: From Haskell To Core diff --git a/ghc/docs/comm/the-beast/modules.html b/ghc/docs/comm/the-beast/modules.html new file mode 100644 index 0000000..a6655a6 --- /dev/null +++ b/ghc/docs/comm/the-beast/modules.html @@ -0,0 +1,80 @@ + + + + + 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. + + -- 1.7.10.4