Version 3 (modified by simonmar@…, 6 years ago) (diff)

Proposal: QualifiedOperators

Type change
Status discussion
Owner Simon Marlow
Section Lexical Syntax
Related replaces QualifiedIdentifiers and CompositionAsDot

Compiler support

GHC full (-XNewQualifiedOperators)
nhc98 none
Hugs none
UHC none
JHC none
LHC none


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.


Report Delta