module-system.md

@@ -58,4 +58,17 @@ I believe this would solve the same problems as the above proposal, but would be
 # 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.
+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 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).
+
+# Permit qualified exports
+
+
+There was a long thread about this on the libraries list.  Details to be filled in here.  Outline:
+
+- module GTK (…, qualified module GTK.Button as Button, …) where
+
+
+The user can import GTK and get all of the contents of GTK.Button imported qualified as Button.