qualified-identifiers.md

-# Fix the lexical syntax for qualified identifiers
-
-**Ticket:**[\#59](https://gitlab.haskell.org//haskell/prime/issues/59)
-
 
 The lexical rules for qualified identifiers lead to some unexpected consequences, and are tricky to implement, such that several existing compilers don't implement them properly.
 
 
+
 eg.
 
-- `M.where` should be 2 lexemes, `M.wher` and `e`. (Hugs treats it as 1, GHC treats it as 3 (see [ http://hackage.haskell.org/trac/ghc/ticket/1215](http://hackage.haskell.org/trac/ghc/ticket/1215))).
-- `M...` should be 2 lexemes, `M..` and `.` (`..` is a reserved symbol and can't be qualified, neigther GHC nor Hugs implements this)
-- `M.\` should be 2 lexemes, `M` and `.\`
+
+- `M.where` should be 3 lexemes (Hugs treats it as 1)
+- `M...` should be 2 lexemes (`..` is a reserved symbol and can't be qualified, neigther GHC nor Hugs implements this)
 
 
-The trickiness in implementation is due to the lookahead required.
+The trickiness in implementation is due to the lookahead required.  GHC deals with the first example with some special case code.
+
 
 
 Fixing the lexical syntax is easy, we define
 
+
 ```wiki
 id -> small {small|large|digit|'}
 varid -> id<reservedid>
@@ -29,13 +28,11 @@ qvarid -> [ modid . ] id
 and similarly for qualified symbols.
 
 
-See also [CompositionAsDot](composition-as-dot), which supercedes this proposal if adopted.
 
-### Cons
+An argument against doing this is that treating `M.where` as a qualified variable isn't very useful, since you can't define a variable called `where`.  Perhaps it should be possible to use qualified identifiers in a definition, to make this consistent again?
+
+
 
-- treating `M.where` as a qualified variable isn't very useful, since you can't define a variable called `where`.  Perhaps it should be possible to use qualified identifiers in a definition, to make this consistent again?
+In favour of making this change: most compilers don't get it right anyway, this is just a small change that makes it easier to implement Haskell.
 
-### Pros
 
-- the consequences of the current lexical syntax are ugly (`M.wher``e` ?) and unintentional.
-- most compilers don't get it right anyway, this is just a small change that makes it easier to implement Haskell.