wiki:QualifiedOperators

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

--

Proposal: QualifiedOperators


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

Compiler support

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

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.

References

Report Delta