Editing Syntactic sugar/Cons (section)

== Examples ==

The following section consider several notations and their specific problems.

=== Infix notation ===

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


==== "Infixisation" ====

You can't pass an argument to a function written in infix notation.
<hask>x `rel c` y</hask> or <hask>x `lift rel` y</hask> is not allowed.

Some library functions are designed for a "reversed" order of arguments,
this means that you will most oftenly leave out the first argument on partial application
rather than the second one.
E.g. the functions <hask>div</hask> and <hask>mod</hask> have parameters in the order of common mathematical notation.
But you will more oftenly use <hask>flip div x</hask> than <hask>div x</hask> and
<hask>flip mod x</hask> more often than <hask>mod x</hask>.
This is because the library designer expect that the user will prefer the infix style,
writing <hask>x `div` y</hask> and thus <hask>`div` y</hask>.

For functions which are not bound to a traditional notation
one should avoid this order!
A bad example in this respect is the module <hask>Data.Bits</hask> in the version that comes with GHC-6.2.
Many of the functions of this module alter some bits in a machine word,
thus they can be considered as update functions and their type signature should end with <hask>a -> a</hask>.
Then you could easily combine several operations by
<haskell>
shiftL 2 . clearBit 7 . setBit 4 . setBit 1
</haskell>
instead of
<haskell>
flip shiftL 2 . flip clearBit 7 . flip setBit 4 . flip setBit 1
</haskell>
or
<haskell>
(`shiftL` 2) . (`clearBit` 7) . (`setBit` 4) . (`setBit` 1)
</haskell>
.


=== Lists ===

==== Special notation for the list type ====

The type of a list over type <hask>a</hask> is named <hask>[a]</hask> rather than <hask>List a</hask>.
This is confusing, since <hask>[a]</hask> looks like the notation of a single element list.
For beginners it becomes even more complicated to distinguish between the type and the value of a list.
Some people try to do some kind of [[list comprehension]] by enclosing expressions in brackets
just like it is done for the list type.
See [[Singleton list confusion]].

I don't see the advantage of <hask>[a]</hask> and would like to see <hask>List a</hask> in [[Haskell two]].


==== Comma separated list elements ====

We are used to the [[list notation]] <hask>[0,1,2,3]</hask>.
I think many Haskell users are not aware that it is a special notation.
They don't know that it is a replacement for <hask>(0:1:2:3:[])</hask>,
and because of that they also can't derive
that a function for constructing single element list can be written as <hask>(:[])</hask>.

The comma separated list notation <hask>[0,1,2,3]</hask> is very common, but is it sensible?
There are two reasons against:

* The theoretical reason: The intuitive list notation using comma separation requires one comma less than the number of elements, an empty list would need -1 commas, which can't be written, obviously.
* The practical reason: The colon is like a terminator. Each list element is followed by the colon, thus it is easier to reorder the elements of a list in an editor. If you have written <hask>(1:2:3:[])</hask> you can simply cut some elements and the subsequent ':' and then you can insert them whereever you want.


Although the list type has so many special support by the Haskell 98 language,
there is no need for some syntactic support.
The definition

data List a = End | (:) a (List a)

is regular Haskell98 code.
The colon should have precedence below <hask>($)</hask>.
Then a list type can be <hask>List Int</hask> and
a list value can be <hask>1 : 2 : 3 : End</hask>.

Again, this proves the power of the basic features of Haskell98.


==== Parallel list comprehension ====

Parallel list comprehension can be replaced by using <hask>zip</hask> in many (all?) cases.