Personal tools

Syntactic sugar/Cons

From HaskellWiki

< Syntactic sugar(Difference between revisions)
Jump to: navigation, search
(moved from Hawiki)
 
(HaskellWiki syntax highlighting)
Line 8: Line 8:
 
and digs into details that are not essential for the situation they describe.
 
and digs into details that are not essential for the situation they describe.
 
For this purpose special syntaxes
 
For this purpose special syntaxes
like {{{do}}} syntax, guards, list notation, list comprehension, infix notation
+
like <hask>do</hask> syntax, guards, list notation, list comprehension, infix notation
 
were introduced
 
were introduced
 
for some frequent programming tasks
 
for some frequent programming tasks
Line 49: Line 49:
 
in current versions of Haskell compilers.
 
in current versions of Haskell compilers.
 
Infix notation for alphanumeric functions is already possible in Haskell98
 
Infix notation for alphanumeric functions is already possible in Haskell98
but "lacks" the possibility to add arguments like in {{{x `rel c` y}}}.
+
but "lacks" the possibility to add arguments like in <hask>x `rel c` y</hask>.
 
The last is not implemented, but was already requested.
 
The last is not implemented, but was already requested.
 
A solution using only Haskell98 infix operators is already invented
 
A solution using only Haskell98 infix operators is already invented
Line 78: Line 78:
 
E.g. when a parser reads an opening bracket
 
E.g. when a parser reads an opening bracket
 
it doesn't know whether it is the start of a list comprehension expression
 
it doesn't know whether it is the start of a list comprehension expression
like {{{[f x | x <- xs]}}}
+
like <hask>[f x | x <- xs]</hask>
 
or the start of a list of comma separated expressions
 
or the start of a list of comma separated expressions
like {{{[f x, f y, g z]}}}.
+
like <hask>[f x, f y, g z]</hask>.
 
Thus if you accidentally mix bars and commas
 
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.
 
the parser don't know if you wanted to write a list comprehension or a comma separated list.
Line 92: Line 92:
 
Let's consider another example from the view of a compiler.
 
Let's consider another example from the view of a compiler.
 
Internally it transforms the source code
 
Internally it transforms the source code
{{{#!syntax haskell
+
<haskell>
 
(+1)
 
(+1)
}}}
+
</haskell>
 
to
 
to
{{{#!syntax haskell
+
<haskell>
 
flip (+) 1
 
flip (+) 1
}}}
+
</haskell>
 
then it compiles it like regular functional code.
 
then it compiles it like regular functional code.
 
Though what happens if it encounters an error?
 
Though what happens if it encounters an error?
Line 105: Line 105:
 
type error in
 
type error in
 
flip (+) 1
 
flip (+) 1
}}}
+
</haskell>
 
(as Hugs November 2002)
 
(as Hugs November 2002)
 
you wouldn't understand it,
 
you wouldn't understand it,
because you typed {{{(+1)}}} but not {{{flip (+) 1}}}.
+
because you typed <hask>(+1)</hask> but not <hask>flip (+) 1</hask>.
 
A compiler which handles this properly
 
A compiler which handles this properly
 
must support syntactic sugar at the same level like regular syntax
 
must support syntactic sugar at the same level like regular syntax
Line 138: Line 138:
 
but it is not true for some syntactic sugar.
 
but it is not true for some syntactic sugar.
   
E.g. {{{map}}} can be used with partial application
+
E.g. <hask>map</hask> can be used with partial application
 
which is not possible for list comprehension syntax.
 
which is not possible for list comprehension syntax.
Thus {{{map toLower}}} can be generalised to lists of strings simply by lifting {{{map toLower}}} with {{{map}}}, again, leading to {{{map (map toLower)}}}.
+
Thus <hask>map toLower</hask> can be generalised to lists of strings simply by lifting <hask>map toLower</hask> with <hask>map</hask>, again, leading to <hask>map (map toLower)</hask>.
In contrast to that {{{\s -> [toLower c | c <- s]}}}
+
In contrast to that <hask>\s -> [toLower c | c <- s]</hask>
has to be turned into {{{\ss -> [[toLower c | c <- s] | s <- ss]}}}
+
has to be turned into <hask>\ss -> [[toLower c | c <- s] | s <- ss]</hask>
or {{{\ss -> map (\s -> [toLower c | c <- s]) ss}}}.
+
or <hask>\ss -> map (\s -> [toLower c | c <- s]) ss</hask>.
   
 
A function can get more arguments as the development goes on.
 
A function can get more arguments as the development goes on.
If you are used to write {{{x `rel` y}}} then you have to switch to {{{rel c x y}}}
+
If you are used to write <hask>x `rel` y</hask> then you have to switch to <hask>rel c x y</hask>
after you added a new parameter to {{{rel}}}.
+
after you added a new parameter to <hask>rel</hask>.
The extended infix notation {{{x `rel c` y}}} is (currently?) not allowed,
+
The extended infix notation <hask>x `rel c` y</hask> is (currently?) not allowed,
probably because then also nested infixes like in {{{x `a `superRel` b` y}}} must be handled.
+
probably because then also nested infixes like in <hask>x `a `superRel` b` y</hask> must be handled.
The prefix notation {{{rel x y}}} tends to need less rewriting.
+
The prefix notation <hask>rel x y</hask> tends to need less rewriting.
   
Guards need to be rewritten to {{{if}}}s or to ["Case"] statements
+
Guards need to be rewritten to <hask>if</hask>s or to ["Case"] statements
 
when the result of a function needs post-processing.
 
when the result of a function needs post-processing.
 
Say we have the functions
 
Say we have the functions
{{{#!syntax haskell
+
<haskell>
 
isLeapYear :: Int -> Bool
 
isLeapYear :: Int -> Bool
 
isLeapYear year = mod year 4 == 0 && (mod year 100 /= 0 || mod year 400 == 0)
 
isLeapYear year = mod year 4 == 0 && (mod year 100 /= 0 || mod year 400 == 0)
Line 163: Line 163:
 
| isLeapYear year = "A leap year"
 
| isLeapYear year = "A leap year"
 
| otherwise = "Not a leap year"
 
| otherwise = "Not a leap year"
}}}
+
</haskell>
where {{{leapYearText}}} shall be extended to other languages
+
where <hask>leapYearText</hask> shall be extended to other languages
using the fictitious function {{{translate}}}.
+
using the fictitious function <hask>translate</hask>.
 
If you stick to guards you will possibly rewrite it to the clumsy
 
If you stick to guards you will possibly rewrite it to the clumsy
{{{#!syntax haskell
+
<haskell>
 
leapYearText :: Language -> Int -> String
 
leapYearText :: Language -> Int -> String
 
leapYearText lang year =
 
leapYearText lang year =
Line 173: Line 173:
 
| isLeapYear year -> "A leap year"
 
| isLeapYear year -> "A leap year"
 
| otherwise -> "Not a leap year")
 
| otherwise -> "Not a leap year")
}}}
+
</haskell>
 
But what about
 
But what about
{{{#!syntax haskell
+
<haskell>
 
leapYearText :: Language -> Int -> String
 
leapYearText :: Language -> Int -> String
 
leapYearText lang year =
 
leapYearText lang year =
Line 181: Line 181:
 
then "A leap year"
 
then "A leap year"
 
else "Not a leap year")
 
else "Not a leap year")
}}}
+
</haskell>
So if you find that simpler why not using {{{if}}} also in the original definition?
+
So if you find that simpler why not using <hask>if</hask> also in the original definition?
{{{#!syntax haskell
+
<haskell>
 
leapYearText :: Int -> String
 
leapYearText :: Int -> String
 
leapYearText year =
 
leapYearText year =
Line 189: Line 189:
 
then "A leap year"
 
then "A leap year"
 
else "Not a leap year"
 
else "Not a leap year"
}}}
+
</haskell>
   
   
Line 210: Line 210:
 
The same problem arises for source code formatters.
 
The same problem arises for source code formatters.
 
You certainly prefer the formatting
 
You certainly prefer the formatting
{{{#!syntax haskell
+
<haskell>
 
a +
 
a +
 
b * c
 
b * c
}}}
+
</haskell>
 
to
 
to
{{{#!syntax haskell
+
<haskell>
 
a + b *
 
a + b *
 
c
 
c
}}}
+
</haskell>
because the first formatting reflects the high precedence of {{{*}}}.
+
because the first formatting reflects the high precedence of <hask>*</hask>.
 
A source code formatter can format this properly
 
A source code formatter can format this properly
 
only if it has access to the imported modules.
 
only if it has access to the imported modules.
Line 228: Line 228:
   
 
You can't pass an argument to a function written in infix notation.
 
You can't pass an argument to a function written in infix notation.
{{{x `rel c` y}}} or {{{x `lift rel` y}}} is not allowed.
+
<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,
 
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
 
this means that you will most oftenly leave out the first argument on partial application
 
rather than the second one.
 
rather than the second one.
E.g. the functions {{{div}}} and {{{mod}}} have parameters in the order of common mathematical notation.
+
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 {{{flip div x}}} than {{{div x}}} and
+
But you will more oftenly use <hask>flip div x</hask> than <hask>div x</hask> and
{{{flip mod x}}} more often than {{{mod x}}}.
+
<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,
 
This is because the library designer expect that the user will prefer the infix style,
writing {{{x `div` y}}} and thus {{{`div` y}}}.
+
writing <hask>x `div` y</hask> and thus <hask>`div` y</hask>.
   
 
For functions which are not bound to a traditional notation
 
For functions which are not bound to a traditional notation
 
one should avoid this order!
 
one should avoid this order!
A bad example in this respect is the module {{{Data.Bits}}} in the version that comes with GHC-6.2.
+
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,
 
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 {{{a -> a}}}.
+
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
 
Then you could easily combine several operations by
{{{#!syntax haskell
+
<haskell>
 
shiftL 2 . clearBit 7 . setBit 4 . setBit 1
 
shiftL 2 . clearBit 7 . setBit 4 . setBit 1
}}}
+
</haskell>
 
instead of
 
instead of
{{{#!syntax haskell
+
<haskell>
 
flip shiftL 2 . flip clearBit 7 . flip setBit 4 . flip setBit 1
 
flip shiftL 2 . flip clearBit 7 . flip setBit 4 . flip setBit 1
}}}
+
</haskell>
 
or
 
or
{{{#!syntax haskell
+
<haskell>
 
(`shiftL` 2) . (`clearBit` 7) . (`setBit` 4) . (`setBit` 1)
 
(`shiftL` 2) . (`clearBit` 7) . (`setBit` 4) . (`setBit` 1)
}}}
+
</haskell>
 
.
 
.
   
Line 263: Line 263:
 
=== Special notation for the list type ===
 
=== Special notation for the list type ===
   
The type of a list over type {{{a}}} is named {{{[a]}}} rather than {{{List a}}}.
+
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 {{{[a]}}} looks like the notation of a single element list.
+
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.
 
For beginners it becomes even more complicated to distinguish between the type and the value of a list.
 
Some people try to turn some expression into a list by enclosing it in brackets
 
Some people try to turn some expression into a list by enclosing it in brackets
 
just like it is done for the list type.
 
just like it is done for the list type.
   
I don't see the advantage of {{{[a]}}} and would like to see {{{List a}}} in HaskellTwo.
+
I don't see the advantage of <hask>[a]</hask> and would like to see <hask>List a</hask> in HaskellTwo.
   
   
 
=== Comma separated list elements ===
 
=== Comma separated list elements ===
   
We are used to the list notation {{{[0,1,2,3]}}}.
+
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.
 
I think many Haskell users are not aware that it is a special notation.
They don't know that it is a replacement for {{{(0:1:2:3:[])}}},
+
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
 
and because of that they also can't derive
that a function for constructing single element list can be written as {{{(:[])}}}.
+
that a function for constructing single element list can be written as <hask>(:[])</hask>.
   
The comma separated list notation {{{[0,1,2,3]}}} is very common, but is it sensible?
+
The comma separated list notation <hask>[0,1,2,3]</hask> is very common, but is it sensible?
 
There are two reasons against:
 
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 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 {{{(1:2:3:[])}}} you can simply cut some elements and the subsequent ':' and then you can insert them whereever you want.
+
* 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.
   
   
Line 294: Line 294:
   
 
is regular Haskell98 code.
 
is regular Haskell98 code.
The colon should have precedence below {{{($)}}}.
+
The colon should have precedence below <hask>($)</hask>.
Then a list type can be {{{List Int}}} and
+
Then a list type can be <hask>List Int</hask> and
a list value can be {{{1 : 2 : 3 : End}}}.
+
a list value can be <hask>1 : 2 : 3 : End</hask>.
   
 
Again, this proves the power of the basic features of Haskell98.
 
Again, this proves the power of the basic features of Haskell98.
Line 303: Line 303:
 
=== Parallel list comprehension ===
 
=== Parallel list comprehension ===
   
Parallel list comprehension can be replaced by using {{{zip}}} in many (all?) cases.
+
Parallel list comprehension can be replaced by using <hask>zip</hask> in many (all?) cases.
   
   
Line 315: Line 315:
 
= If-Then-Else =
 
= If-Then-Else =
   
The construction {{{if}}}-{{{then}}}-{{{else}}} can be considered as syntactic sugar for a function {{{if}}} of type {{{Bool -> a -> a -> a}}} as presented on ["Case"].
+
The construction <hask>if</hask>-<hask>then</hask>-<hask>else</hask> can be considered as syntactic sugar for a function <hask>if</hask> of type <hask>Bool -> a -> a -> a</hask> as presented on ["Case"].
The definition as plain function had the advantages that it can be used with {{{foldr}}} and {{{zipWith3}}} and
+
The definition as plain function had the advantages that it can be used with <hask>foldr</hask> and <hask>zipWith3</hask> and
that {{{then}}} and {{{else}}} became regular identifiers.
+
that <hask>then</hask> and <hask>else</hask> became regular identifiers.
Some people prefer the explicit {{{then}}} and {{{else}}} for readability reasons.
+
Some people prefer the explicit <hask>then</hask> and <hask>else</hask> for readability reasons.
 
A generalisation of this syntactic exception was already proposed as "MixFix" notation.
 
A generalisation of this syntactic exception was already proposed as "MixFix" notation.
 
(http://www.dcs.gla.ac.uk/mail-www/haskell/msg02005.html)
 
(http://www.dcs.gla.ac.uk/mail-www/haskell/msg02005.html)
 
But it's worth to turn round the question:
 
But it's worth to turn round the question:
What is so special about {{{if}}} that it need a special syntax?
+
What is so special about <hask>if</hask> that it need a special syntax?
   
   
 
= Conclusion =
 
= Conclusion =
   
* Guards can be dropped completely. {{{if}}} should be turned into a regular function. {{{case expr of}}} could be turned into a function, i.e. {{{case 0 -> 'a'; 1 -> 'b';}}} could an expression of type {{{Int -> Char}}}. It should be complemented by {{{select}}} function like that in ["Case"].
+
* Guards can be dropped completely. <hask>if</hask> should be turned into a regular function. <hask>case expr of</hask> could be turned into a function, i.e. <hask>case 0 -> 'a'; 1 -> 'b';</hask> could an expression of type <hask>Int -> Char</hask>. It should be complemented by <hask>select</hask> function like that in ["Case"].
* Infix notation is good for nested application, because {{{(0:1:2:[])}}} reflects the represented structure better than {{{((:) 0 ((:) 1 ((:) 2 [])))}}}.
+
* Infix notation is good for nested application, because <hask>(0:1:2:[])</hask> reflects the represented structure better than <hask>((:) 0 ((:) 1 ((:) 2 [])))</hask>.
* Infix usage of functions with alphanumeric names is often just a matter of habit, just for the sake of fanciness, such as {{{toLower `map` s}}} which doesn't add anything to readability. If this feature is kept it should remain restricted to function names. It should not be extended to partially applied functions.
+
* Infix usage of functions with alphanumeric names is often just a matter of habit, just for the sake of fanciness, such as <hask>toLower `map` s</hask> which doesn't add anything to readability. If this feature is kept it should remain restricted to function names. It should not be extended to partially applied functions.
* List comprehension should be used rarely, parallel list comprehension should be dropped completely.
+
* List comprehension should be used rarely, parallel list comprehension should be dropped completely.
* {{{do}}} notation is good for representing imperative and stateful program structures.
+
* <hask>do</hask> notation is good for representing imperative and stateful program structures.
* {{{(n+k)}}} patterns simulate a number representation which is not used internally and thus it must be emulated with much effort. It should be dropped. Numeric patterns such as {{{0}}} involve conversions like {{{fromInteger}}} and real comparisons ({{{Eq}}} class!) for matching. It should be thought about dropping them, too.
+
* <hask>(n+k)</hask> patterns simulate a number representation which is not used internally and thus it must be emulated with much effort. It should be dropped. Numeric patterns such as <hask>0</hask> involve conversions like <hask>fromInteger</hask> and real comparisons (<hask>Eq</hask> class!) for matching. It should be thought about dropping them, too.

Revision as of 14:00, 13 October 2006

This page is dedicated to arguments against syntactic sugar. The request for extended syntactic sugar is present everywhere and the reasons for syntactic sugar are obvious, but there are also serious objections to them. The objections listed here may help to decide when to do without syntactic sugar and which special notations should better be dropped in future versions of Haskell.


Contents

1 General

Haskell's basic syntax consists of function definition and function application. Though in some cases function application is hard to read and digs into details that are not essential for the situation they describe. For this purpose special syntaxes

like
do
syntax, guards, list notation, list comprehension, infix notation

were introduced for some frequent programming tasks to allow a more pleasant look.

Many people seem to like Haskell only because of its syntactic sugar. But adding syntactic sugar to a language is not a big achievement. Python, Perl, C++ have lots of syntactic sugar, but I wouldn't prefer them to Haskell. Why? Because they lack the transparency of data dependency of functional programming languages, they lack static but easy to use polymorphism, they lack lazy evaluation, they lack reliable modularisation. It's not amazing that Haskell provides a lot of syntactic sugar. It's amazing that every syntactic sugar has pure functional explanations. That proves the power of the functional concept.


1.1 Syntactic heroin

Compiler writers can only lose if they give way to the insistence of users requesting more syntactic sugar. Every user has his own preferred applications, everyone has his taste and everyone wants his special application and his taste to be respected in future language revisions. Who is authorised to decide which application is general and which is too special? Is it more important to have many syntactic alternatives such that all people can write with their individual styles or is it more important that code of several authors have homogenous appearance such that it can be read by all people?

You can bet if new syntactic sugar arises many users will rush at it and forget about the analytic expression the special notation shall replace. To argue against that is like trying to take the most beloved toy from children.

Every special notation leads to the question if it can be extended and generalised. Guards are extended to PatternGuards and ListComprehension is generalised to ParallelListComprehension in current versions of Haskell compilers. Infix notation for alphanumeric functions is already possible in Haskell98

but "lacks" the possibility to add arguments like in
x `rel c` y
.

The last is not implemented, but was already requested. A solution using only Haskell98 infix operators is already invented (http://www.haskell.org/pipermail/haskell-cafe/2002-July/003215.html). Further on, the more general "MixFix" notation was already proposed (http://www.dcs.gla.ac.uk/mail-www/haskell/msg02005.html), not to forget the silent lifting of map data structures to functions (http://www.haskell.org/pipermail/haskell/2002-October/010629.html). What comes next?

Someone called the phenomena not only "syntactic sugar" but "syntactic heroin".

http://www.cs.wichita.edu/~rodney/languages/Modula-Ada-comparison.txt

People start with a small dosis of syntactic sugar, they quickly want more, because the initial dosis isn't enough for ecstasy any longer. If one drug no longer helps then stronger ones are requested. It is so much tempting because the users requesting syntactic sugar are not responsible for implementing it and for avoiding inferences with other language features.


1.2 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
[f x | x <- xs]

or the start of a list of comma separated expressions

like
[f x, f y, g z]
.

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

(+1)

to

flip (+) 1

then it compiles it like regular functional code. Though what happens if it encounters an error? If it reports the error like {{{ type error in flip (+) 1 </haskell> (as Hugs November 2002) you wouldn't understand it,

because you typed
(+1)
but not
flip (+) 1
.

A compiler which handles this properly must support syntactic sugar at the same level like regular syntax which is obviously more complicated.


1.3 Sugar adds complexity

Syntactic sugar does not only touch the compilers. Many other tools like those for syntax highlighting (emacs, nedit), source code markup (lhs2TeX), source code formatting (Language.Haskell.Pretty), source code transform (e.g. symbolic differentation), program proofs, debugging, dependency analysis, documentation extraction (haddock) are affected.

Each tool becomes more complicated by more syntactic sugar.


1.4 Flexibility

The use of functions and functions of functions (i.e. higher order functions) allows for very flexible usage of program units. This is also true for the function notation, but it is not true for some syntactic sugar.

E.g.
map
can be used with partial application

which is not possible for list comprehension syntax.

Thus
map toLower
can be generalised to lists of strings simply by lifting
map toLower
with
map
, again, leading to
map (map toLower)
. In contrast to that
\s -> [toLower c | c <- s]
has to be turned into
\ss -> [[toLower c | c <- s] | s <- ss]
or
\ss -> map (\s -> [toLower c | c <- s]) ss
.

A function can get more arguments as the development goes on.

If you are used to write
x `rel` y
then you have to switch to
rel c x y
after you added a new parameter to
rel
. The extended infix notation
x `rel c` y
is (currently?) not allowed, probably because then also nested infixes like in
x `a `superRel` b` y
must be handled. The prefix notation
rel x y
tends to need less rewriting. Guards need to be rewritten to
if
s or to ["Case"] statements

when the result of a function needs post-processing. Say we have the functions

isLeapYear :: Int -> Bool
isLeapYear year = mod year 4 == 0 && (mod year 100 /= 0 || mod year 400 == 0)
 
leapYearText :: Int -> String
leapYearText year
   | isLeapYear year = "A leap year"
   | otherwise       = "Not a leap year"
where
leapYearText
shall be extended to other languages using the fictitious function
translate
.

If you stick to guards you will possibly rewrite it to the clumsy

leapYearText :: Language -> Int -> String
leapYearText lang year =
   translate lang (case () of ()
      | isLeapYear year -> "A leap year"
      | otherwise       -> "Not a leap year")

But what about

leapYearText :: Language -> Int -> String
leapYearText lang year =
   translate lang (if (isLeapYear year)
                     then "A leap year"
                     else "Not a leap year")
So if you find that simpler why not using
if
also in the original definition?
leapYearText :: Int -> String
leapYearText year =
   if (isLeapYear year)
     then "A leap year"
     else "Not a leap year"


2 Examples

The following section consider several notations and their specific problems.

2.1 Infix notation

2.1.1 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

a +
 b * c

to

a + b *
 c
because the first formatting reflects the high precedence of
*
.

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.


2.1.2 "Infixisation"

You can't pass an argument to a function written in infix notation.

x `rel c` y
or
x `lift rel` y
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
div
and
mod
have parameters in the order of common mathematical notation. But you will more oftenly use
flip div x
than
div x
and
flip mod x
more often than
mod x
.

This is because the library designer expect that the user will prefer the infix style,

writing
x `div` y
and thus
`div` y
.

For functions which are not bound to a traditional notation one should avoid this order!

A bad example in this respect is the module
Data.Bits
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
a -> a
.

Then you could easily combine several operations by

shiftL 2 . clearBit 7 . setBit 4 . setBit 1

instead of

flip shiftL 2 . flip clearBit 7 . flip setBit 4 . flip setBit 1

or

(`shiftL` 2) . (`clearBit` 7) . (`setBit` 4) . (`setBit` 1)

.


2.2 Lists

2.2.1 Special notation for the list type

The type of a list over type
a
is named
[a]
rather than
List a
. This is confusing, since
[a]
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 turn some expression into a list by enclosing it in brackets just like it is done for the list type.

I don't see the advantage of
[a]
and would like to see
List a
in HaskellTwo.


2.2.2 Comma separated list elements

We are used to the list notation
[0,1,2,3]
.

I think many Haskell users are not aware that it is a special notation.

They don't know that it is a replacement for
(0:1:2:3:[])
,

and because of that they also can't derive

that a function for constructing single element list can be written as
(:[])
. The comma separated list notation
[0,1,2,3]
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
    (1:2:3:[])
    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
($)
. Then a list type can be
List Int
and a list value can be
1 : 2 : 3 : End
.

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


2.2.3 Parallel list comprehension

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


3 (n+k) patterns

Therer are some notational ambiguities concerning (n+k) patterns.

http://www.dcs.gla.ac.uk/mail-www/haskell/msg01131.html (Why I hate n+k)


4 If-Then-Else

The construction
if
-
then
-
else
can be considered as syntactic sugar for a function
if
of type
Bool -> a -> a -> a
as presented on ["Case"]. The definition as plain function had the advantages that it can be used with
foldr
and
zipWith3
and that
then
and
else
became regular identifiers. Some people prefer the explicit
then
and
else
for readability reasons.

A generalisation of this syntactic exception was already proposed as "MixFix" notation. (http://www.dcs.gla.ac.uk/mail-www/haskell/msg02005.html) But it's worth to turn round the question:

What is so special about
if
that it need a special syntax?


5 Conclusion

  • Guards can be dropped completely.
    if
    should be turned into a regular function.
    case expr of
    could be turned into a function, i.e.
    case 0 -> 'a'; 1 -> 'b';
    could an expression of type
    Int -> Char
    . It should be complemented by
    select
    function like that in ["Case"].
  • Infix notation is good for nested application, because
    (0:1:2:[])
    reflects the represented structure better than
    ((:) 0 ((:) 1 ((:) 2 [])))
    .
  • Infix usage of functions with alphanumeric names is often just a matter of habit, just for the sake of fanciness, such as
    toLower `map` s
    which doesn't add anything to readability. If this feature is kept it should remain restricted to function names. It should not be extended to partially applied functions.
  • List comprehension should be used rarely, parallel list comprehension should be dropped completely.
  • do
    notation is good for representing imperative and stateful program structures.
  • (n+k)
    patterns simulate a number representation which is not used internally and thus it must be emulated with much effort. It should be dropped. Numeric patterns such as
     
    involve conversions like
    fromInteger
    and real comparisons (
    Eq
    class!) for matching. It should be thought about dropping them, too.