X-Git-Url: http://git.megacz.com/?a=blobdiff_plain;f=docs%2Fusers_guide%2Fseparate_compilation.xml;h=1bdb0c5344d716cf7ef2410950a16c8f1d514c0c;hb=52f600c8ea0bf0d9b4c01570e80d70bfa65c43ba;hp=f963ca010c3b3a6049c2c8745697a4993c765958;hpb=5263c9ab4408e3b62dbf7505ab40a81946d4e49b;p=ghc-hetmet.git
diff --git a/docs/users_guide/separate_compilation.xml b/docs/users_guide/separate_compilation.xml
index f963ca0..1bdb0c5 100644
--- a/docs/users_guide/separate_compilation.xml
+++ b/docs/users_guide/separate_compilation.xml
@@ -595,9 +595,9 @@ $ ghc -c parse/Foo.hs parse/Bar.hs gurgle/Bumble.hs -odir `arch`
- Where file is the name of
+ where file is the name of
an interface file, dumps the contents of that interface in
- a human-readable (ish) format.
+ a human-readable (ish) format. See .
@@ -702,7 +702,10 @@ module B where
hi-boot files
Here A imports B, but B imports
A with a {-# SOURCE #-} pragma, which breaks the
-circular dependency. For every module A.hs that is {-# SOURCE #-}-imported
+circular dependency. Every loop in the module import graph must be broken by a {-# SOURCE #-} import;
+or, equivalently, the module import graph must be acyclic if {-# SOURCE #-} imports are ignored.
+
+For every module A.hs that is {-# SOURCE #-}-imported
in this way there must exist a source file A.hs-boot. This file contains an abbreviated
version of A.hs, thus:
@@ -1184,8 +1187,31 @@ and GHC has no other reason for visiting the module. Example:
class C a where ...
Here, neither D nor T is declared in module Orphan.
-We call such modules “orphan modules”,
-defined thus:
+We call such modules “orphan modules”.
+GHC identifies orphan modules, and visits the interface file of
+every orphan module below the module being compiled. This is usually
+wasted work, but there is no avoiding it. You should therefore do
+your best to have as few orphan modules as possible.
+
+
+Functional dependencies complicate matters. Suppose we have:
+
+ module B where
+ instance E T Int where ...
+ data T = ...
+
+Is this an orphan module? Apparently not, because T
+is declared in the same module. But suppose class E had a
+functional dependency:
+
+ module Lib where
+ class E x y | y -> x where ...
+
+Then in some importing module M, the constraint (E a Int) should be "improved" by setting
+a = Int, even though there is no explicit mention
+of T in M.
+
+These considerations lead to the following definition of an orphan module:
An orphan moduleorphan module
@@ -1193,12 +1219,21 @@ defined thus:
least one orphan rule. An instance declaration in a module M is an orphan instance if
- orphan instance
- none of the type constructors
- or classes mentioned in the instance head (the part after the “=>”) are declared
- in M.
-
- Only the instance head counts. In the example above, it is not good enough for C's declaration
+ orphan instance
+
+
+ The class of the instance declaration is not declared in M, and
+
+
+Either the class has no functional dependencies, and none of the type constructors
+ in the instance head is declared in M; or there
+ is a functional dependency for which none of the type constructors mentioned
+ in the non-determined part of the instance head is defined in M.
+
+
+
+ Only the instance head (the part after the “=>”)
+ counts. In the example above, it is not good enough for C's declaration
to be in module A; it must be the declaration of D or T.
@@ -1210,16 +1245,11 @@ defined thus:
- GHC identifies orphan modules, and visits the interface file of
-every orphan module below the module being compiled. This is usually
-wasted work, but there is no avoiding it. You should therefore do
-your best to have as few orphan modules as possible.
-
-
- You can identify an orphan module by looking in its interface
+GHC will warn you if you are creating an orphan module, if you add `-fwarn-orphan-modules`.
+You can identify an orphan module by looking in its interface
file, M.hi, using the
-. If there is a “!” on the
+ mode. If there is a [orphan module] on the
first line, GHC considers it an orphan module.