[[project @ 2002-06-27 12:17:47 by simonmar]
simonmar**20020627121748
Improve the documentation for hierarchical libraries.
] {
hunk ./ghc/docs/users_guide/glasgow_exts.sgml 2388
- A module name in the extended syntax consists of a
- sequence of components, each separated by a dot. When searching
- for an interface file (or a source file, in the case of GHCi or
- when using ) for an imported module, GHC
- interprets the dot as a path separator. So for example, if a
- module A.B.C is imported, then for each
- directory D on the search path (see the
- option, ), GHC will look in the
- directory D/A/BOn Windows,
- this would be D\A\B. for an
- interface file called C.hi or a source file
- C.hs or C.lhs.
-
- Note that as far as the compiler is concerned, module
- names are always fully qualified; the hierarchy only has a
- special meaning when searching for interface files and source
- files in the filesystem. In particular, this means that the
- full module name must be given after the
+ This extension has very little impact on the language
+ itself; modules names are always fully
+ qualified, so you can just think of the fully qualified module
+ name as the module name. In particular, this
+ means that the full module name must be given after the
hunk ./ghc/docs/users_guide/glasgow_exts.sgml 2399
+
+ It is a common strategy to use the as
+ keyword to save some typing when using qualified names with
+ hierarchical modules. For example:
+
+
+import qualified Control.Monad.ST.Strict as ST
+
+
+ Hierarchical modules have an impact on the way that GHC
+ searches for files. For a description, see .
+
hunk ./ghc/docs/users_guide/glasgow_exts.sgml 2418
- url="http://www.haskell.org/~simonmar/libraries/libraries.html">.
+ url="http://www.haskell.org/~simonmar/libraries/libraries.html">Haskell
+ Libraries.
hunk ./ghc/docs/users_guide/separate_compilation.sgml 122
+
+
+ Finding interfaces for hierarchical modules
+
+ GHC supports a hierarchical module namespace as an
+ extension to Haskell 98 (see ).
+
+ A module name in general consists of a sequence of
+ components separated by dots
+ (‘.’). When looking for
+ interface files for a hierarchical module, the compiler turns
+ the dots into path separators, so for example a module
+ A.B.C becomes A/B/C (or
+ A\B\C under Windows). Then each component of
+ the import directories list is tested in turn; so for example if
+ the list contains directories
+ D1 to
+ Dn, then the compiler
+ will look for the interface in
+ D1/A/B/C.hi first,
+ then D2/A/B/C.hi and
+ so on.
+
+ Note that it's perfectly reasonable to have a module which
+ is both a leaf and a branch of the tree. For example, if we
+ have modules A.B and
+ A.B.C, then A.B's
+ interface file will be in A/B.hi and
+ A.B.C's interface file will be in
+ A/B/C.hi.
+
+ For GHCi and , the search strategy
+ for source files is exactly the same, just replace the
+ .hi suffix in the above description with
+ .hs or .lhs.
+
hunk ./ghc/docs/users_guide/using.sgml 446
+
+ The source files for the program don't all need to be in the
+ same directory; the option can be used to add
+ directories to the search path (see ).
+
}