| ... | ... | @@ -8,11 +8,12 @@ The lexical rules for qualified identifiers lead to some unexpected consequences |
|
|
|
|
|
|
|
eg.
|
|
|
|
|
|
|
|
- `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)
|
|
|
|
- `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 `.\`
|
|
|
|
|
|
|
|
|
|
|
|
The trickiness in implementation is due to the lookahead required. GHC deals with the first example with some special case code.
|
|
|
|
The trickiness in implementation is due to the lookahead required.
|
|
|
|
|
|
|
|
|
|
|
|
Fixing the lexical syntax is easy, we define
|
| ... | ... | @@ -36,4 +37,5 @@ See also [CompositionAsDot](composition-as-dot), which supercedes this proposal |
|
|
|
|
|
|
|
### 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. |
