Syntactic sugar

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

Language processors, including compilers, static analyzers, and the like, often expand sugared constructs into more fundamental constructs before processing, a process sometimes called "desugaring".

Origins

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.

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.

Notable examples

• Augmented assignment or compound assignment operators: For example, a += b is equivalent to a = a + b in C and similar languages.
• Properties in C#: The construct may be called syntactic sugar — it is roughly, but not exactly equivalent to a getter-setter pair of functions.
• Operator overloading in C++: Using overloaded operator is semantically equivalent to calling a function, e.g. a+b*c equates to add(a, multiply(b, c)) .
• List comprehension in Python.

Criticism

Some programmers feel that these syntax usability features are either unimportant or outright frivolous. For example, Alan Perlis once quipped, in a reference to bracket-delimited languages, that "syntactic sugar causes cancer of the semicolon". (See Epigrams on Programming.)

Derivative terms

Syntactic salt

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 or double value to be assigned to a variable declared as an int, 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 switch (unless goto is used) even though it does not allow 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.

Syntactic saccharin

Another extension is syntactic saccharin, meaning gratuitous syntax that does not actually make programming easier.

Notes and references

• Landin, Peter J.; 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 (February and March 1965)
• Landin, Peter J.; Programming Without Imperatives - An Example, Technical report, UNIVAC Systems Programming Research, March 1965
• Landin, Peter J.; Getting Rid of Labels, Technical report, UNIVAC Systems Programming Research, July 1965
• Landin, Peter J.; A Generalization of Jumps and Labels, Report, UNIVAC Systems Programming Research, August 1965, reprinted in Higher-Order and Symbolic Computation, 11, pp. 125–143 (1998)

This article is based on material taken from the Free On-line Dictionary of Computing prior to 1 November 2008 and incorporated under the "relicensing" terms of the GFDL, version 1.3 or later.