X-Git-Url: http://git.megacz.com/?a=blobdiff_plain;ds=sidebyside;f=docs%2Fusers_guide%2Fpackages.xml;fp=docs%2Fusers_guide%2Fpackages.xml;h=4d0cac7035d8b655d3bd95d661bca6450bd4591d;hb=c5a9ed64dab05594bcf871716225ffcbaff6ca7f;hp=3bd65c66ce8c2c19ae837a20a5acf3fb59e7e309;hpb=e7ac000cb44b15af22c03014b59a578ca18cf3bf;p=ghc-hetmet.git
diff --git a/docs/users_guide/packages.xml b/docs/users_guide/packages.xml
index 3bd65c6..4d0cac7 100644
--- a/docs/users_guide/packages.xml
+++ b/docs/users_guide/packages.xml
@@ -137,9 +137,12 @@ exposed-modules: Network.BSD,
base) need to be explicitly exposed using
options.
- This is a good way to insulate your program from differences
- in the globally exposed packages, and being explicit about package
- dependencies is a Good Thing.
+ This is a good way to insulate your program from
+ differences in the globally exposed packages, and being
+ explicit about package dependencies is a Good Thing.
+ Cabal always passes the
+ flag to GHC, for
+ exactly this reason.
@@ -181,27 +184,31 @@ exposed-modules: Network.BSD,
- The module overlap restriction
-
- The module names in a Haskell program must be distinct.
- This doesn't sound like a severe restriction, but in a Haskell program
- using multiple packages with interdependencies, difficulties can start to
- arise. You should be aware of what the module overlap
- restriction means, and how to avoid it.
-
- GHC knows which packages are in use by your
- program: a package is in use if you imported something from it, or if it
- is a dependency of some other package in use. There must be no conflicts
- between the packages in use; a conflict is when two packages contain
- a module with the same name. If
- GHC detects a conflict, it will issue a message stating which packages
- are in conflict, and which modules are overlapping.
-
- For example, a conflict might arise if you use two packages, say P
- and Q, which respectively depend on two different versions of another
- package, say R-1.0 and R-2.0. The
- two versions of R are likely to contain at least some
- of the same modules, so this situation would be a conflict.
+ Consequences of packages
+
+ It is possible that by using packages you might end up with
+ a program that contains two modules with the same name: perhaps
+ you used a package P that has a hidden module
+ M, and there is also a module M in your program. Or perhaps the
+ dependencies of packages that you used contain some overlapping
+ modules. Perhaps the program even contains multiple versions of a
+ certain package, due to dependencies from other packages.
+
+ None of these scenarios gives rise to an error on its
+ ownit used to in GHC 6.4, but not since
+ 6.6, but they may have some interesting
+ consequences. For instance, if you have a type
+ M.T from version 1 of package
+ P, then this is not the
+ same as the type M.T from version 2 of package
+ P, and GHC will report an error if you try to
+ use one where the other is expected.
+
+ Formally speaking, in Haskell 98, an entity (function, type
+ or class) in a program is uniquely identified by the pair of the
+ module name in which it is defined and its name. In GHC, an
+ entity is uniquely defined by a triple: package, module, and
+ name.
@@ -371,11 +378,41 @@ $ export GHC_PACKAGE_PATH=$HOME/.my-ghc-packages.conf:
+ To compile a module which is to be part of a new package,
+ use the -package-name option:
+
+
+
+
+ -package-name
+ option
+
+ This option is added to the command line when
+ compiling a module that is destined to be part of package
+ foo. If this flag is omitted then the
+ default package main is assumed.
+
+ Note: the argument to
+ should be the full package identifier for the package,
+ that is it should include the version number. For example:
+ -package mypkg-1.2.
+
+
+
+
+ Failure to use the -package-name option
+ when compiling a package will probably result in disaster, but
+ you will only discover later when you attempt to import modules
+ from the package. At this point GHC will complain that the
+ package name it was expecting the module to come from is not the
+ same as the package name stored in the .hi
+ file.
+
It is worth noting that on Windows, when each package
is built as a DLL, since a reference to a DLL costs an extra
indirection, intra-package references are cheaper than
inter-package references. Of course, this applies to the
- Main package as well.
+ main package as well.