Proposal: QualifiedOperators

Compiler support

Summary

Change the syntax for qualified operators from Prelude.>>= to Prelude.(>>=).

Description

The problem is that right now, qualified operators are written like

   Prelude.>>=

but the difficulty with this is that we now have lexemes like Prelude.. (qualified '.'), which means for example that

  [Red..]

doesn't parse as you might expect: Red.. is a qualified operator.

The proposal is as follows. Qualified operators are written

  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

  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

  `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.

Summary: pros

• Eliminates odd cases in the lexical syntax: M.., M..., M.... are 1, 2, and 3 lexemes respectively in Haskell 98 (see also QualifiedIdentifiers). This can be confusing, e.g. [Monday..].
• A simple rule: if a lexeme begins with a letter, it is not an infix operator. Infix operators begin with a symbol character or ```.

Summary: cons

• The syntax for infix qualified operators is heavier: Prelude.(>>=) vs. Prelude.>>=
• Using the workaround let (>>=) = Prelude.(>>=) in ... does not work, because >>= has the default fixity.
• ... and (...) are not dual
• we lose some consistency with sections, which become quite unwieldy with the new syntax:

             left section   right section   prefix
unqualified  (+ 1)          (1 +)           (+)
Haskell 98   (M.+ 1)        (1 M.+)         (M.+)
proposed     (`M.(+)` 1)    (1 `M.(+)`)     M.(+)
   or(*)     (flip M.(+) 1) (M.(+) 1)

(*) only if precedence isn't important, e.g. not in cases like ``M.(+)xM.(*)` y`.

Report Delta

Section 2.4

Add

  var     -> varid  |  ( varsym )
  con     -> conid  |  ( consym )

  qvar    -> [ modid . ] var
  qcon    -> [ modid . ] con

  varop   -> varsym  |  `var`
  qvarop  -> varsym  |  `qvar`
  conop   -> consym  |  `con`
  qconop  -> consym  |  `qcon`

remove qvarid, qvarsym, qconid, qvarsym from the description of qualified identifiers. Add text to explain the syntax of qualified operators (moving some of it from 3.2 and updating to the new syntax), and modify the text describing qualified identifiers. Adjust the table of "Sample lexical analyses" according to the new syntax.

tyvar, tycon, tycls, qtycon, qtycls, remain as they are.

Section 3.2

Remove var, con, qvar, qcon, varop, qwvarop, conop, qconop and associated text (some of which moved to 2.4)

Section 9 (Syntax reference)

Make corresponding changes as for 2.4 and 3.2 above.