Syntactic sugar/Cons
From HaskellWiki
(links) 
MatrixFrog (Talk  contribs) m (→General) 

(8 intermediate revisions by 3 users not shown)  
Line 2:  Line 2:  
−  = General = 
+  == General == 
Haskell's basic syntax consists of function definition and function application. 
Haskell's basic syntax consists of function definition and function application. 

Though in some cases function application is hard to read 
Though in some cases function application is hard to read 

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 <hask>do</hask> syntax, guards, list notation, list comprehension, infix notation were introduced for some frequent programming tasks to allow a more pleasant look. 
−  like <hask>do</hask> 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. 
Many people seem to like Haskell only because of its syntactic sugar. 

Line 22:  Line 22:  
−  == Syntactic heroin == 
+  === Syntactic heroin === 
Compiler writers can only lose if they give way 
Compiler writers can only lose if they give way 

Line 47:  Line 47:  
but "lacks" the possibility to add arguments like in <hask>x `rel c` y</hask>. 
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 
−  (http://www.haskell.org/pipermail/haskellcafe/2002July/003215.html). 
+  [http://www.haskell.org/pipermail/haskellcafe/2002July/003215.html invented]. 
−  Further on, the more general "MixFix" notation was already proposed 
+  Further on, the more general [http://www.dcs.gla.ac.uk/mailwww/haskell/msg02005.html MixFix] notation was already proposed, 
−  (http://www.dcs.gla.ac.uk/mailwww/haskell/msg02005.html), 
+  not to forget the silent lifting of map data structures to 
−  not to forget the silent lifting of map data structures to functions 
+  [http://www.haskell.org/pipermail/haskell/2002October/010629.html functions], 
−  (http://www.haskell.org/pipermail/haskell/2002October/010629.html). 
+  [http://www.haskell.org/ghc/docs/latest/html/users_guide/syntaxextns.html postfix operators], 
+  [[section of an infix operatorsections]] of 

+  [http://www.haskell.org/pipermail/haskellcafe/2006July/016683.html tuples], like <hask>(?,x,?)</hask>, 

+  [http://www.haskell.org/pipermail/haskellcafe/2007September/031544.html symbolic prefix operators]. 

What comes next? 
What comes next? 

Rodney Bates called the phenomena not only "syntactic sugar" but "[http://portal.acm.org/citation.cfm?id=1071738 syntactic heroin]". 
Rodney Bates called the phenomena not only "syntactic sugar" but "[http://portal.acm.org/citation.cfm?id=1071738 syntactic heroin]". 

−  (See also http://www.cs.wichita.edu/~rodney/languages/ModulaAdacomparison.txt) 
+  :(See also http://www.cs.wichita.edu/~rodney/languages/ModulaAdacomparison.txt) 
People start with a small dosis of syntactic sugar, 
People start with a small dosis of syntactic sugar, 

−  they quickly want more, because the initial dosis isn't enough for ecstasy any longer. 
+  they quickly want more, because the initial dose isn't enough for ecstasy any longer. 
If one drug no longer helps then stronger ones are requested. 
If one drug no longer helps then stronger ones are requested. 

It is so much tempting because the users requesting syntactic sugar 
It is so much tempting because the users requesting syntactic sugar 

Line 64:  Line 64:  
for avoiding inferences with other language features. 
for avoiding inferences with other language features. 

−  +  === Parse errors === 

−  == Parse errors == 

Compiler users have contradictory wishes. 
Compiler users have contradictory wishes. 

Line 109:  Line 109:  
−  == Sugar adds complexity == 
+  === Sugar adds complexity === 
Syntactic sugar are usually special grammatical constructions. 
Syntactic sugar are usually special grammatical constructions. 

Line 132:  Line 132:  
−  == Flexibility == 
+  === Flexibility === 
The use of functions and functions of functions (i.e. higher order functions) 
The use of functions and functions of functions (i.e. higher order functions) 

Line 192:  Line 192:  
</haskell> 
</haskell> 

−  +  == Examples == 

−  
−  = Examples = 

The following section consider several notations and their specific problems. 
The following section consider several notations and their specific problems. 

−  == Infix notation == 
+  === Infix notation === 
−  === Precedences === 
+  ==== Precedences ==== 
Infix notation is problematic for both human readers 
Infix notation is problematic for both human readers 

Line 222:  Line 222:  
only if it has access to the imported modules. 
only if it has access to the imported modules. 

This is certainly uncommon for a plain source code formatter. 
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. GHC6.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, 
It has been noticed by many people, 

that the integer numbered precedences are not enough for describing the relations of all the infix operators. 
that the integer numbered precedences are not enough for describing the relations of all the infix operators. 

+  http://www.haskell.org/pipermail/haskellcafe/2005February/009260.html 

Fractional and negative fixities were already proposed: 
Fractional and negative fixities were already proposed: 

http://www.haskell.org/pipermail/haskellcafe/2006November/019293.html 
http://www.haskell.org/pipermail/haskellcafe/2006November/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" === 
+  ==== "Infixisation" ==== 
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. 

Line 264:  Line 278:  
−  == Lists == 
+  === Lists === 
−  === Special notation for the list type === 
+  ==== 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>. 
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. 
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 do some kind of [[list comprehension]] by enclosing expressions in brackets 
just like it is done for the list type. 
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]]. 
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 === 
+  ==== Comma separated list elements ==== 
We are used to the [[list notation]] <hask>[0,1,2,3]</hask>. 
We are used to the [[list notation]] <hask>[0,1,2,3]</hask>. 

Line 306:  Line 321:  
−  === Parallel list comprehension === 
+  ==== Parallel list comprehension ==== 
Parallel list comprehension can be replaced by using <hask>zip</hask> in many (all?) cases. 
Parallel list comprehension can be replaced by using <hask>zip</hask> in many (all?) cases. 

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

Line 318:  Line 333:  
−  = IfThenElse = 
+  == IfThenElse == 
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 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]]. 

Line 329:  Line 344:  
−  = Conclusion = 
+  == Conclusion == 
* 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]]. 
* 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]]. 
Latest revision as of 06:51, 6 November 2011
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 
[edit] 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 likeMany 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.
[edit] 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 pattern guards and list comprehension is generalised to parallel list comprehension in current versions of Haskell compilers. Infix notation for alphanumeric functions is already possible in Haskell98
but "lacks" the possibility to add arguments like inThe last is not implemented, but was already requested. A solution using only Haskell98 infix operators is already invented. Further on, the more general MixFix notation was already proposed, not to forget the silent lifting of map data structures to functions, postfix operators, sections of
tuples, likesymbolic prefix operators. What comes next?
Rodney Bates called the phenomena not only "syntactic sugar" but "syntactic heroin".
People start with a small dosis of syntactic sugar, they quickly want more, because the initial dose 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.
[edit] 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
likeor the start of a list of comma separated expressions
likeThus 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
(as Hugs November 2002)
you wouldn't understand it,
A compiler which handles this properly must support syntactic sugar at the same level like regular syntax which is obviously more complicated.
[edit] 1.3 Sugar adds complexity
Syntactic sugar are usually special grammatical constructions. They can interfere badly with other constructions:
But 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.
[edit] 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.which is not possible for list comprehension syntax.
ThusA function can get more arguments as the development goes on.
If you are used to writewhen the result of a function needs postprocessing. 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"
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")
leapYearText :: Int > String leapYearText year = if (isLeapYear year) then "A leap year" else "Not a leap year"
[edit] 2 Examples
The following section consider several notations and their specific problems.
[edit] 2.1 Infix notation
[edit] 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
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. GHC6.4.1 may say then
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: `$'
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/haskellcafe/2005February/009260.html
Fractional and negative fixities were already proposed:
http://www.haskell.org/pipermail/haskellcafe/2006November/019293.html
Indeed, rules like "multiplication and division precede addition and subtraction" would be more natural.
[edit] 2.1.2 "Infixisation"
You can't pass an argument to a function written in infix notation.
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 functionsThis is because the library designer expect that the user will prefer the infix style,
writingFor functions which are not bound to a traditional notation one should avoid this order!
A bad example in this respect is the moduleMany 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 withThen 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)
.
[edit] 2.2 Lists
[edit] 2.2.1 Special notation for the list type
The type of a list over typeFor 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
[edit] 2.2.2 Comma separated list elements
We are used to the list notationI think many Haskell users are not aware that it is a special notation.
They don't know that it is a replacement forand because of that they also can't derive
that a function for constructing single element list can be written asThere 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 you can simply cut some elements and the subsequent ':' and then you can insert them whereever you want.(1:2:3:[])
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 belowAgain, this proves the power of the basic features of Haskell98.
[edit] 2.2.3 Parallel list comprehension
Parallel list comprehension can be replaced by using
[edit] 3 (n+k) patterns
Therer are some notational ambiguities concerning (n+k) patterns.
See Why I hate n+k
[edit] 4 IfThenElse
The constructionA generalisation of this syntactic exception was already proposed as "MixFix" notation. But it's worth to turn round the question:
What is so special about
[edit] 5 Conclusion
 Guards can be dropped completely. should be turned into a regular function.ifcould be turned into a function, i.e.case expr ofcould an expression of typecase 0 > 'a'; 1 > 'b';. It should be complemented byInt > Charfunction like that in Case.select
 Infix notation is good for nested application, because reflects the represented structure better than(0:1:2:[]).((:) 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 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.toLower `map` s
 List comprehension should be used rarely, parallel list comprehension should be dropped completely.
 notation is good for representing imperative and stateful program structures.do
 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(n+k)involve conversions likeand real comparisons (fromIntegerclass!) for matching. It should be thought about dropping them, too.Eq