|Version 3 (modified by simonmar@…, 6 years ago) (diff)|
|Related||replaces QualifiedIdentifiers and CompositionAsDot|
Change the syntax for qualified operators from Prelude.>>= to Prelude.(>>=).
The problem is that right now, qualified operators are written like
but the difficulty with this is that we now have lexemes like Prelude.. (qualified '.'), which means for example that
doesn't parse as you might expect: Red.. is a qualified operator.
The proposal is as follows. Qualified operators are written
and are prefix; that is, the above is a qualified version of (>>=). One obvious advantage is that this is much easier to read: the dot is clearly separated from the operator being qualified.
Prelude.(>>=) has to be a single lexeme, because there's no way to lift the syntax of qualified names into the context-free grammar. So this forces us to move the syntax for parenthesized operators and `..` down to the lexical syntax (back where it was in Haskell 1.2?). But that's not too bad; one possibility for the lexical grammar is
var -> varid | ( varsym ) qvar -> [ modid . ] var varop -> varsym | `var` qvarop -> varsym | `qvar`
(with identical rules for constructors). This grammar has slightly fewer productions than Haskell 98.
Note that this grammar is nested differently than in Haskell 98: the layering is
- varid: plain variables
- var: adds parenthesised operators
- qvar: adds qualification
- qvarop: adds ..
So, an infix qualified operator is written
for consistency we also allow `(>>=)`. The fixity of these would be the same as the fixity of >>=.
You might argue that it is inconsistent to allow `(+)` but not allow (`plus`), but the justification is simply that (..) and `..` are not dual in this design.
This proposal simplifies the story for composition: we don't have to worry about whether you need a space after Prelude... Also, Prelude.(.) is much easier to read. The only disadvantage I can see is that it could break some code, but probably very little.