Editing Syntactic sugar

{{short description|Programming language syntax designed for ease of use}}
In [[computer science]], '''syntactic sugar''' is [[Syntax (programming languages)|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. Syntactic sugar is usually a shorthand for a common operation that could also be expressed in an alternate, more verbose, form: The programmer has a choice of whether to use the shorter form or the longer form, but will usually use the shorter form since it is shorter and easier to type and read.

For example, many programming languages provide special syntax for referencing and updating [[Array data type|array]] elements. Abstractly, an array reference is a procedure of two arguments: an array and a subscript vector, which could be expressed as <code>get_array(Array, vector(i,j))</code>. Instead, many languages provide syntax such as <code>Array[i,j]</code>. Similarly an array element update is a procedure consisting of three arguments, for example <code>set_array(Array, vector(i,j), value)</code>, but many languages also provide syntax such as <code>Array[i,j] = value</code>.

A construct in a language is syntactic sugar if it can be removed from the language without any effect on what the language can do: [[Function (engineering)|functionality]] and [[expressive power (computer science)|expressive power]] will remain the same.

Language processors, including [[compiler]]s and [[Static program analysis|static analyzers]], often expand sugared constructs into their more verbose equivalents 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]],<ref>{{cite journal |last=Landin |first=Peter J. |date=1964 |title=The mechanical evaluation of expressions |url=https://www.cs.cmu.edu/~crary/819-f09/Landin64.pdf |journal= The Computer Journal|publisher=[[Computer Journal]] |volume=6 |issue=4 |pages=308–320 |doi=10.1093/comjnl/6.4.308 |access-date=21 July 2014|doi-access=free }}</ref>{{sfn|Abelson|Sussman|1996|loc=Chapter 1, [http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-10.html#footnote_Temp_17 footnote 11]}}<!-- reference credits coinage to Landin, hence included --> centered on lexically replacing λ with "where".

Later programming languages, such as [[CLU (programming language)|CLU]], [[ML (programming language)|ML]] and [[Scheme (programming language)|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.<ref>Barbara Liskov, "A History of CLU", MIT Laboratory for Computer Science Technical Report 561 (1993)</ref> This is, in fact, the usual mathematical practice of building up from primitives.

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.<ref>{{cite journal|last=Felleisen|first=Matthias|date=December 1991|title=On the Expressive Power of Programming Languages|url=http://www.cs.rice.edu/CS/PLT/Publications/Scheme/scp91-felleisen.ps.gz|journal=Science of Computer Programming|publisher=Springer-Verlag|volume=17|issue=1–3|pages=35–75|doi=10.1016/0167-6423(91)90036-W|access-date=19 July 2014|doi-access=free}}</ref>

== Notable examples ==
* In [[COBOL]], many of the intermediate keywords are syntactic sugar that may optionally be omitted. For example, the sentence <code>MOVE A B.</code> and the sentence <code>MOVE A TO B.</code> perform exactly the same function, but the second makes the action to be performed clearer.
* [[Augmented assignment]] or compound assignment operators: For example, <code>a&nbsp;+=&nbsp;b</code> is equivalent to <code>a = a + b</code> in C and similar languages, assuming <code>a</code> has no side effects such as if <code>a</code> is a regular variable.<ref>{{cite web |url=https://msdn.microsoft.com/en-us/library/e1wf2hxf.aspx |title=C Compound Assignment |author=<!--Staff writer(s); no by-line.--> |website=msdn.microsoft.com |publisher=Microsoft |access-date=20 June 2016 |quote=However, the compound-assignment expression is not equivalent to the expanded version because the compound-assignment expression evaluates expression1 only once, while the expanded version evaluates expression1 twice: in the addition operation and in the assignment operation.}}</ref><ref>{{cite web |url=http://programmers.stackexchange.com/a/134136 |title=Why are shortcuts like x += y considered good practice? |last1=Garavaglia |first1=Emilio |date=26 July 2015 |website=stackexchange.com |access-date=20 June 2016 |quote=optimization can [be done] if 'finding x' has no side effects}}</ref> Some languages, such as [[Python (programming language)|Python]]<ref>{{cite web |url=https://docs.python.org/3/reference/datamodel.html#object.__iadd__ |title=Python Data model |date=21 December 2020 |website=docs.python.org}}</ref> may allow [[operator overloading|overloading]] augmented assignment operators, so they may behave differently than standard ones.
* In [[Perl]], <code>unless (condition) {...} </code> is syntactic sugar for <code>if (not condition) {...}</code>. Additionally, any statement can be followed by a condition, so <code>statement if condition</code> is equivalent to <code>if (condition) {statement}</code>, but the former is more naturally formatted on a single line.
* In the [[C (programming language)|C language]], the <code>a[i]</code> notation is syntactic sugar for <code>*(a + i)</code>.<ref name="Raymond1996">{{cite book|first=Eric S.|last=Raymond|title=The New Hacker's Dictionary – 3rd Edition|url=https://books.google.com/books?id=g80P_4v4QbIC&pg=PA432|access-date=5 August 2012|date=11 October 1996|publisher=MIT Press|isbn=978-0-262-68092-9|page=432}}</ref> Likewise, the <code>a->x</code> notation is syntactic sugar for [[C syntax#Accessing members|accessing members]] using the [[dereference operator]] <code>(*a).x</code>.
* The <code>using</code> statement in [[C Sharp (programming language)|C#]] ensures that certain objects are disposed of correctly. The compiler expands the statement into a [[Exception handling|try-finally]] block.<ref>{{cite web|title=using Statement (C# Reference)|url=http://msdn.microsoft.com/en-ca/library/yh598w02.aspx|access-date=16 September 2014}}</ref>
* The C# language allows variables to be declared as <code>var x = expr</code>, which allows the compiler to [[Type inference|infer]] the type of <code>x</code> from the expression <code>expr</code>, instead of requiring an explicit type declaration. Similarly, C++ allows <code>auto x = expr</code> since C++11 and Java allows <code>var x = expr</code> since Java 11.
* Python [[Comparison_of_programming_languages_(list_comprehension)#Python|list comprehensions]] (such as <code>[x*x for x in range(10)]</code> for a list of squares) and [[Python syntax and semantics#Decorators|decorators]] (such as <code>@staticmethod</code>).
* In [[Haskell (programming language)|Haskell]], a string, denoted in quotation marks, is semantically equivalent to a list of characters. An optional language extension ''OverloadedStrings'' allows string literals to produce other types of values, such as Text, as well.
* In the [[tidyverse]] collection of [[R (programming language)|R]] packages, the ''pipe'', denoted by <code>%>%</code>, declares that the data (or output of the function) preceding the pipe will serve as the first argument for the function following the pipe.<ref>{{cite web |title=magrittr: Vignette |url=https://cran.r-project.org/web/packages/magrittr/vignettes/magrittr.html |access-date=24 December 2018}}</ref> So, <code>x %>% f(y)</code> is equivalent to <code>f(x,y)</code>.
* In [[SQL]], a mere <code>JOIN</code> is equivalent to an <code>INNER JOIN</code>, the latter clarifying that the join statement is specifically an inner join operation as opposed to an outer join operation. Likewise, one may omit the <code>OUTER</code> from the <code>LEFT OUTER JOIN</code>, <code>RIGHT OUTER JOIN</code> and <code>FULL OUTER JOIN</code>.
*[[Extension method]] in OOP languages in the form of <code>'''myObject'''.myMethod(parameter1, parameter2, parameter3)</code> is syntactic sugar for calling a global function as <code>myMethod('''myObject''', parameter1, parameter2, parameter3)</code>. The reference to the object is passed as a hidden argument, usually accessible from within the method as '''<code>this</code>'''.
*[[Evaluation strategy#Call by reference|A parameter called by reference]] is syntactic sugar for technically passing a ''pointer'' as the parameter, but syntactically handling it as the variable itself, to avoid constant pointer de-referencing in the code inside the function.
* In [[Java (Programming Language)|Java]], an <code>import</code> declaration enables the compiler to find classes that are not otherwise specified with fully qualified names. For example <code>import javax.swing.*;</code> allows the programmer to reference a [[Swing (Java)|Swing]] object such as <code>javax.swing.JButton</code> using the shorter name <code>JButton</code>.
* In the [[ES6]] version of [[JavaScript]], arrow functions have a short form <code>(x) => x + 1</code>, which is equivalent to the longer form <code>(x) => { return x + 1; }</code>.
* In [[Scala (programming language)|Scala]], triple questions marks (<code> ??? </code>) is equivalent to <code> throw new NotImplementedError </code>. This is useful to mark a place for code that has not yet been written.<ref>{{cite web|url=https://stackoverflow.com/questions/31302524/what-does-the-triple-question-mark-mean-in-scala|title=Stack Overflow: What does the triple question mark mean in scala?|access-date=23 January 2024}}</ref>
* In [[JavaScript]], if the key and value are the same in an object, you can only write it once. For example, <code>{name: name}</code> is equivalent to <code>{name}</code>. This is called the Shorthand Property.

== Criticism ==
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 view is particularly widespread in the [[Lisp (programming language)|Lisp]] community, as Lisp has very simple and regular syntax, and the surface syntax can easily be modified.{{sfn|Abelson|Sussman|1996|loc=Chapter 1, [https://web.mit.edu/alexmv/6.037/sicp.pdf#page=43 footnote 11]}}
For example, [[Alan Perlis]] once quipped in "[[Epigrams on Programming]]", in a reference to [[Curly bracket programming language|bracket-delimited languages]], that "Syntactic sugar causes cancer of the [[Semicolon#Programming|semi-colons]]".{{sfn|Perlis|1982|loc=Epigram #3}}

== 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.<ref>{{cite web |url=http://www.catb.org/jargon/html/S/syntactic-salt.html |title=The Jargon File - syntactic salt |date=2003-06-12 |access-date=2018-03-19 |archive-url=https://web.archive.org/web/20030612232319/http://www.catb.org/jargon/html/S/syntactic-salt.html |archive-date=2003-06-12}}</ref> Specifically, syntactic salt is a hoop that programmers must jump through just to prove that they know what is going on, rather than to express a program action.

In [[C Sharp (programming language)|C#]], when hiding an inherited class member, a compiler warning is issued unless the <code>new</code> keyword is used to specify that the hiding is intentional.<ref>{{cite web|url=http://msdn.microsoft.com/en-us/library/435f1dw2.aspx|title=new Modifier (C# Reference)|publisher=Microsoft|work=microsoft.com|access-date=3 August 2015}}</ref> To avoid potential bugs owing to the similarity of the [[switch statement]] syntax with that of C or C++, C# requires a <code>break</code> for each non-empty <code>case</code> label of a <code>switch</code> (unless <code>[[goto]]</code>, <code>return</code>, or <code>throw</code> is used) even though it does not allow implicit ''fall-through''.<ref>{{cite web |url=http://msdn.microsoft.com/en-us/library/vstudio/06tc147t.aspx |title=switch (C# Reference) |publisher=Microsoft |work=microsoft.com |access-date=3 August 2015}}</ref> (Using <code>goto</code> 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&nbsp;– in extreme cases, the essential part of the 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&nbsp;– a practice common in modern C/C++ compilers.

=== Syntactic saccharin ===
Other extensions are ''syntactic [[saccharin]]'' and ''syntactic [[syrup]]'', meaning gratuitous syntax that does not make programming any easier.<ref>{{cite web|url=http://www.catb.org/jargon/html/S/syntactic-sugar.html|title=syntactic sugar|work=catb.org|access-date=3 August 2015}}</ref><ref>{{cite book|url=https://books.google.com/books?id=OfWiZNhyRGgC&q=syntactic+saccharin+example&pg=PA93|title=Mathematics of Program Construction|access-date=3 August 2015|isbn=9783540438571|last1=Boiten|first1=Eerke A.|last2=Möller|first2=Bernhard|date=2002-06-26|publisher=Springer }}</ref><ref>{{cite book |last=Dean |first=Thomas |date=2004 |title=Talking with Computers: Explorations in the Science and Technology of Computing |url=https://archive.org/details/talkingwithcompu00dean |url-access=registration |publisher=Cambridge University Press |page=[https://archive.org/details/talkingwithcompu00dean/page/115 115] |isbn=9780521542043}}</ref><ref>{{cite conference |url=https://pdfs.semanticscholar.org/f396/bc99c7e444f70db69fb3f42e76e94e9d39a3.pdf |archive-url=https://web.archive.org/web/20170331115339/https://pdfs.semanticscholar.org/f396/bc99c7e444f70db69fb3f42e76e94e9d39a3.pdf |url-status=dead |archive-date=March 31, 2017 |chapter=Fine control of demand in Haskell |last1=Harrison |first1=William |last2=Sheard |first2=Tim |title=Mathematics of Program Construction |series=Lecture Notes in Computer Science |date=July 8–10, 2002 |volume=2386 |publisher=Springer Berlin Heidelberg |book-title=Mathematics of Program Construction: 6th International Conference, MPC 2002, Dagstuhl Castle, Germany, July 8–10, 2002. Proceedings |pages=93 |location=Dagstuhl Castle, Germany |doi=10.1007/3-540-45442-X_6 |isbn=978-3-540-43857-1 |s2cid=10059915 |conference=International Conference on Mathematics of Program Construction }}</ref>

=== Sugared types ===
Data types with core syntactic support are said to be "sugared types".<ref>{{cite thesis |type=PhD |last=Chugh |first=Ravi |date=2013 |title=Nested Refinement Types for JavaScript |publisher=UC San Diego}}</ref><ref>{{cite web|url=http://clang.llvm.org/doxygen/SemaCodeComplete_8cpp_source.html|title=C Language LLVM Documentation|work=clang.llvm.org|access-date=30 June 2020}}</ref><ref>{{cite web|url=https://medium.com/@slavapestov/the-secret-life-of-types-in-swift-ff83c3c000a5|title=The Secret Life of Types in Swift|work=medium.com/@slavapestov| date=14 July 2016 |access-date=30 June 2020}}</ref> Common examples include quote-delimited strings, curly braces for object and record types, and square brackets for arrays.

== Notes ==
{{Reflist}}

== References ==
{{refbegin}}
* {{Cite book | isbn = 0-262-51087-1 | title = Structure and Interpretation of Computer Programs | last1 = Abelson | first1 = Harold | author-link1 = Harold Abelson | last2 = Sussman | first2 = Gerald Jay | author-link2 = Gerald Jay Sussman | first3 = Julie | last3 = Sussman | year = 1996 | orig-year = 1984 | publisher = [[MIT Press]] | location = Cambridge, MA | ref = {{SfnRef|AbelsonSussman1996}} | title-link = Structure and Interpretation of Computer Programs }}
* {{cite journal | last = Landin | first = Peter J. | title = A Correspondence Between ALGOL 60 and Church's Lambda-Notation: Parts I and II | journal = Communications of the ACM | volume = 8 | issue = 2.3 | pages = 89–101, 158–165 | date = February–March 1965 | doi=10.1145/363744.363749| s2cid = 6505810 | doi-access = free }}
* {{cite journal | last = Landin | first = Peter J. | title = Programming Without Imperatives – An Example <!-- |format = Technical report -->| journal = UNIVAC Systems Programming Research | date = March 1965 }}
* {{cite journal | last = Landin | first = Peter J. | title = Getting Rid of Labels <!-- |format = Technical report -->| journal = UNIVAC Systems Programming Research | date = July 1965 }}
* {{cite journal | last = Landin | first = Peter J. | title = A Generalization of Jumps and Labels <!-- |format = Report -->| journal = UNIVAC Systems Programming Research | date = August 1965 }}, reprinted in {{cite journal | title = ''Higher-Order and Symbolic Computation'' | citeseerx = 10.1.1.85.2610 | volume = 11 | pages = 125–143 | date = 1998 }}
* {{Cite journal | last1 = Perlis | first1 = A. J. | doi = 10.1145/947955.1083808 | title = Epigrams on programming | journal = ACM SIGPLAN Notices | publisher = Association for Computing Machinery| location = New York, NY, USA| volume = 17| issue = 9| pages = 7–13 | date=September 1982 | s2cid = 20512767 | url = http://www-pu.informatik.uni-tuebingen.de/users/klaeren/epigrams.html| archive-url = https://web.archive.org/web/19990117034445/http://www-pu.informatik.uni-tuebingen.de/users/klaeren/epigrams.html| archive-date = January 17, 1999 | doi-access = free }}
{{refend}}

[[Category:Programming language syntax]]
[[Category:Computer jargon]]
[[Category:Source code]]
[[Category:Programming language design]]
[[Category:Metaphors referring to food and drink]]