Syntactic sugar
From Wikipedia, the free encyclopedia
Syntactic sugar is a term coined by Peter J. Landin for additions to the syntax of a computer language that do not affect its expressiveness but make it "sweeter" for humans to use. Syntactic sugar gives the programmer (designer, in the case of specification computer languages) an alternative way of coding (specifying) that is more practical, either by being more succinct or more like some familiar notation. It does not affect the expressiveness of the formalism.
Syntactic sugar can be easily translated ("desugared") to produce a program (specification) in some simpler "core" syntax. In Landin's case, the core was a lambda calculus enriched with a few operations, such as assignment. Following Landin's insights, some later programming languages, such as ML and Scheme, were explicitly designed as a language core of essential constructs, into which other convenient features can be desugared. This is, in fact, the usual mathematical practice of starting from a minimal set of primitives, but doing most work in a convenient, special-purpose notation defined in terms of those primitives.
For instance, while it is common for most programming languages to include standard mathematical operations using infix notation (you will often find operations such as i + 1 throughout a typical program's source code) many of these languages (mainly those that are functional languages), handle the actual math by calling functions. In these cases the infix notation is actually syntactic sugar for something such as (add i 1).
Another example is in the C's handling of arrays. In C, arrays are constructed as blocks of memory, accessed via an offset from the array's starting point in memory. However, pointer mathematics can often be "tricky" and error prone, so C provides the a[i] syntax for what would otherwise be written as *(a + i). Similarly a[i][j] is easier to understand than *(*(a + i) + j).
Alan Perlis once quipped, in a reference to bracket-delimited languages that "Syntactic sugar causes cancer of the semicolon."
Contents |
[edit] Syntactic salt
The metaphor has been extended by coining the term syntactic salt, a feature designed to make it harder to write bad code. Specifically, syntactic salt is a hoop the programmer must jump through just to prove that he knows what's going on, rather than to express a program action. Some programmers consider required type declarations to be syntactic salt. A requirement to write "end if", "end while", "end do", etc. to terminate the last block controlled by a control construct (as opposed to just "end") is widely considered syntactic salt. Critics deride languages rich in salt as bondage and discipline languages.
The correct amount of both syntactic sugar and syntactic salt in a language is a matter of personal opinion, and thus is the subject of never-ending debate.
[edit] Syntactic saccharin
Another extension is syntactic saccharin. Just as saccharin sweetens without providing real food energy, syntactic saccharine is purported to ease programming without actually doing so.
[edit] Syntactic Splenda
Another extension is syntactic Splenda. Syntactic Splenda is an extension to Syntactic Sugar, coined by Kip Porterfield. Just as Splenda sweetens without providing real food energy, syntactic splenda is when a programmer modifies code written with syntactic sugar. The modification to the code or syntactic sugar is purported to make programming easier, but makes the code extremely difficult to understand and often introduces subtle bugs.
[edit] Syntactic heroin
Rodney Bates used the term syntactic heroin [1] for syntactic extensions, that seem to simplify things at first, but then make programmers want more of it.
This finally ends up with a disaster, namely that code becomes very compact, but no human is able to analyze what the code actually means.
This article was originally based on material from the Free On-line Dictionary of Computing, which is licensed under the GFDL.
