In computer science, syntactic sugar is syntax within a programming language that is designed to make things easier to read or to express. It makes the language "sweeter" for human use: things can be expressed more clearly, more concisely, or in an alternative style that some may prefer.
For example, many programming languages provide special syntax for referencing and updating array elements. Abstractly, an array reference is simply a procedure of two arguments: an array and a subscript vector, which could be expressed as
get_array(Array, vector(i,j)). Instead, many languages provide special syntax like
Array[i,j] . Similarly an array element update is abstractly something like
set_array(Array, vector(i,j), value), but many languages provide syntax like
Array[i,j] := value.
Specifically, a construct in a language is called syntactic sugar if it can be removed from the language without any effect on what the language can do: functionality and expressive power will remain the same. For instance, in the C language the
a[i] notation is syntactic sugar for
*(a + i).
The term syntactic sugar was coined by Peter J. Landin in 1964 to describe the surface syntax of a simple ALGOL-like programming language which was defined semantically in terms of the applicative expressions of lambda calculus, centered around lexically replacing λ with "where".
Building on Landin's distinction between essential language constructs and syntactic sugar, in 1991, Matthias Felleisen proposed a codification of "expressive power" to align with "widely held beliefs" in the literature. He defined "more expressive" to mean that without the language constructs in question, a program would have to be completely reorganized.
Later programming languages, such as CLU, Racket, ML and Scheme, extended the term to refer to syntax within a language which could be defined in terms of a language core of essential constructs; the convenient, higher-level features could be "desugared" and decomposed into that subset. This is, in fact, the usual mathematical practice of building up from primitives.
- Augmented assignment or compound assignment operators: For example,
a += bis equivalent to
a = a + bin C and similar languages.
- Parallel assignment: several assignments can be combined in one statement; for example,
a = x; b = ycan instead be written as
a, b = x, y(assuming all the variables are distinct). This is particularly used for exchanging the values of two variables, where in some languages one can write
a, b = b, ainstead of
temp = a; a = b; b = temp.
- Properties: The construct may be called syntactic sugar—it is roughly, but not exactly equivalent to a getter-setter pair of functions.
- Operator overloading: Using an overloaded operator is semantically equivalent to calling a function, e.g.
a + b * cequates to
add(a, multiply(b, c)).
- List comprehension in Python.
- Decorators in Python.
Some programmers feel that these syntax usability features are either unimportant or outright frivolous. Notably, special syntactic forms make a language less uniform and its specification more complex, and may cause problems as programs become large and complex. This is particularly widespread in the Lisp community, as Lisp has very simple and regular syntax, and the surface syntax can easily be modified. For example, Alan Perlis once quipped in "Epigrams on Programming", in a reference to bracket-delimited languages, that "Syntactic sugar causes cancer of the semi-colons".
The metaphor has been extended by coining the term syntactic salt, which indicates a feature designed to make it harder to write bad code. Specifically, syntactic salt is a hoop programmers must jump through just to prove that they know what's going on, rather than to express a program action. For example, Java will not allow a float value to be assigned to a variable declared as an int without additional syntax explicitly stating that intention, while C and C++ will automatically truncate any floats assigned to an int.
In C#, when hiding an inherited class member, a compiler warning is issued unless the
new keyword is used to specify that the hiding is intentional. To avoid potential bugs owing to the similarity of the switch statement syntax with that of C or C++, C# requires a
break for each non-empty
case label of a
throw is used) even though it does not allow fall-through. (Using
goto and specifying the subsequent label produces a C/C++-like fall-through.)
Syntactic salt may defeat its purpose by making the code unreadable and thus worsen its quality – in extreme cases, useful code may be shorter than the overhead introduced to satisfy language requirements. An alternative to syntactic salt is generating compiler warnings when there is high probability that the code is a result of a mistake – a practice common in modern C/C++ compilers.
- Eric S. Raymond (11 October 1996). The New Hacker's Dictionary - 3rd Edition. MIT Press. p. 432. ISBN 978-0-262-68092-9. Retrieved 5 August 2012.
- Landin, Peter J. (1964). The mechanical evaluation of expressions 6 (4). Computer Journal. pp. 308–320. doi:10.1093/comjnl/6.4.308. Retrieved 21 July 2014.
- Abelson & Sussman 1996, Chapter 1, footnote 11.
- Felleisen, Matthias (December 1991). "On the Expressive Power of Programming Languages". Science of Computer Programming (Springer-Verlag) 17 (1-3): 35–75. doi:10.1016/0167-6423(91)90036-W. Retrieved 19 July 2014.
- Barbara Liskov, "A History of CLU", MIT Laboratory for Computer Science Technical Report 561 (1993)
- Perlis 1982, Epigram #3.
- new Modifier (C# Reference) - Visual Studio 2012
- switch (C# Reference) - Visual Studio 2012
- The Jargon File v4.4.7: "syntactic sugar"
||This article includes a list of references, but its sources remain unclear because it has insufficient inline citations. (July 2007)|
- Abelson, Harold; Sussman, Gerald Jay; Sussman, Julie (1996) . Structure and Interpretation of Computer Programs. Cambridge, MA: MIT Press. ISBN 0-262-51087-1.
- Landin, Peter J. (February and March 1965). "A Correspondence Between ALGOL 60 and Church's Lambda-Notation: Parts I and II". Communications of the ACM 8 (2.3): 89–101, 158–165.
- Landin, Peter J. (March 1965). "Programming Without Imperatives - An Example". UNIVAC Systems Programming Research (Technical report).
- Landin, Peter J. (July 1965). "Getting Rid of Labels". UNIVAC Systems Programming Research (Technical report).
- Landin, Peter J. (August 1965). "A Generalization of Jumps and Labels". UNIVAC Systems Programming Research (Report)., reprinted in Higher-Order and Symbolic Computation 11. 1998. pp. 125–143. CiteSeerX: 10.1.1.85.2610.
- Perlis, A. J. (September 1982). "Epigrams on programming". ACM SIGPLAN Notices (New York, NY, USA: Association for Computing Machinery) 17 (9): 7–13. doi:10.1145/947955.1083808. Archived from the original on January 17, 1999.