module-system.md

@@ -48,20 +48,12 @@ Some compilers distinguish these namespaces, others do not.
 ## Alternative proposal
 
 
-There has been past discussion on mailing lists about clarifying the import/export namespace in a different way.  Each type or class constructor in an import or export list could be annotated with its namespace, e.g.
-
-- import Foo (class Foo (Foo,Bar), data Baz())
-
-
-I believe this would solve the same problems as the above proposal, but would be much less backward-compatible.
+There has been past discussion on mailing lists about clarifying the import/export namespace in a different way: [TagExportsWithNamespace](tag-exports-with-namespace).
+I believe this would solve most of the same problems as the above proposal.
 
 # Permit Signatures in Export Lists
 
-
-There is a good case to be made for permitting the inclusion of function signatures in the export list of a module.  People often write them there anyway in comments, but the comments are not checked against the implementation, so changes can go unnoticed.  There is also a good software engineering principle that says you should specify your interfaces as fully as possible. Signatures in export lists should be considered equivalant to signatures specified in the module itself at the top level for all purposes.  If there are signatures in both the interface and the implementation, they should be identical (not just unifiable).
-
-
-If we /required/ signatures in export lists (and always required a full export list too), this would solve the recursive module problem for some compilers very simply.  The export list would represent exactly the information currently contained in ghc's hs-boot files (and nhc98's hand-written .hi bootstrapping method). Other compilers such as jhc and helium have no problem with recursive modules as is.
+[PermitSignaturesInExports](permit-signatures-in-exports)
 
 # Permit qualified exports