infix-type-constructors.md

@@ -77,7 +77,7 @@ And `type` gets an extra production:
    data a `Bar` b = a `BAR` b
   ```
 
-## Issues
+## Lexical ambiguity
 
 
 The second proposal—-to treat all infix operators as type constructors—-leads to an ambiguity in import/export declarations:
@@ -87,8 +87,14 @@ module Test ( (+) ) where
 ```
 
 
-This export declaration is ambiguous because it is not clear if we mean to export the value operator (+), the type constructor (+), or both.
-A similar issue arises with imports.
+This export declaration is ambiguous because it is not clear if we mean to export the value operator (+), the type constructor (+), or both.  Exactly the same issue arises for
+
+- export lists
+- import lists
+- fixity declarations
+- GHC's RULEs (see [ http://hackage.haskell.org/trac/ghc/ticket/2600](http://hackage.haskell.org/trac/ghc/ticket/2600)) and ANN annotations
+
+### Solution A
 
 
 One possible solution is to state that, when written on their own, infix operators in import/export specifications refer to the value level.
@@ -104,6 +110,8 @@ module Test ( (+)() ) where
 
 Unfortunately, such specifications look rather odd.
 
+### Solution B
+
 
 Another solution would be to introduce a new piece of syntax which would translate to the same thing.  Perhaps:
 
@@ -112,7 +120,10 @@ module Test ( type (+) ) where
 ```
 
 
-The intention here is that `type` specifies the namespace of the following name, and not that it is a type synonym.
+The intention here is that `type` specifies the namespace of the following name, and not that it is a type synonym.  Haskell already allows `module M` in export lists, for the same reason. It might make sense to allow `class C` as well.  
+
+
+Arguably `value C` would make sense too, meaning "the data constructor `C`" which currently cannot be mentioned in an export or import list except in the form `T(C)`.  But that would mean a new keyword, albeit only in this context.
 
 ## References