Editing Syntactic sugar/Cons (section)

=== Parse errors ===

Compiler users have contradictory wishes.
On the one hand they want more syntactic sugar,
on the other hand they want better parser error messages.
They don't realize that one is quite the opposite of the other.

E.g. when a parser reads an opening bracket
it doesn't know whether it is the start of a list comprehension expression
like <hask>[f x | x <- xs]</hask>
or the start of a list of comma separated expressions
like <hask>[f x, f y, g z]</hask>.
Thus if you accidentally mix bars and commas
the parser don't know if you wanted to write a list comprehension or a comma separated list.
So it can't tell you precisely what you made wrong.

Type error messages of GHC have already reached a complexity
which can't be processed by many Haskell newbies.
It is the price to be paid for a type system
which tries to cope with as few as possible type hints.

Let's consider another example from the view of a compiler.
Internally it transforms the source code
<haskell>
(+1)
</haskell>
to
<haskell>
flip (+) 1
</haskell>
then it compiles it like regular functional code.
Though what happens if it encounters an error?
If it reports the error like
<code>
type error in
flip (+) 1
</code>
(as Hugs November 2002)
you wouldn't understand it,
because you typed <hask>(+1)</hask> but not <hask>flip (+) 1</hask>.
A compiler which handles this properly
must support syntactic sugar at the same level like regular syntax
which is obviously more complicated.