|
|
|
# Proposal: Change the syntax of qualified operators
|
|
|
|
|
|
|
|
|
|
|
|
The problem is that right now, qualified operators are written like
|
|
|
|
|
|
|
|
```wiki
|
|
|
|
Prelude.>>=
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
|
|
but the difficulty with this is that we now have lexemes like `Prelude..` (qualified '.'), which means for example that
|
|
|
|
|
|
|
|
```wiki
|
|
|
|
[Red..]
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
|
|
doesn't parse as you might expect: `Red..` is a qualified operator.
|
|
|
|
|
|
|
|
|
|
|
|
The proposal is as follows. Qualified operators are written
|
|
|
|
|
|
|
|
```wiki
|
|
|
|
Prelude.(>>=)
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
|
|
|
|
```wiki
|
|
|
|
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
|
|
|
|
|
|
|
|
```wiki
|
|
|
|
`Prelude.(>>=)`
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
|
|
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. |