Editing Syntactic sugar/Cons (section)

==== Precedences ====

Infix notation is problematic for both human readers
and source code formatters.
The reader doesn't know the precedences of custom infix operators,
he has to read the modules which the operators are imported from.
This is even more difficult because infix operators
are usually imported unqualified,
that is you don't know from which module an operator is imported.
The same problem arises for source code formatters.
You certainly prefer the formatting
<haskell>
a +
 b * c
</haskell>
to
<haskell>
a + b *
 c
</haskell>
because the first formatting reflects the high precedence of <hask>*</hask>.
A source code formatter can format this properly
only if it has access to the imported modules.
This is certainly uncommon for a plain source code formatter.

The problem also occurs if you use an infix operator, that you did forget to import.
E.g. GHC-6.4.1 may say then
<code>
  Main.hs:52:6:
      precedence parsing error
          cannot mix `($)' [infixl 9] and `(.)' [infixr 9] in the same infix expression

  Main.hs:52:13: Not in scope: `$'
</code>
Actually, only the second error is relevant.


It has been noticed by many people,
that the integer numbered precedences are not enough for describing the relations of all the infix operators.
http://www.haskell.org/pipermail/haskell-cafe/2005-February/009260.html
Fractional and negative fixities were already proposed:
http://www.haskell.org/pipermail/haskell-cafe/2006-November/019293.html
Indeed, rules like "multiplication and division precede addition and subtraction" would be more natural.
However, the <hask>Show</hask> class would no longer be so simple.