Syntactic sugar is a concept in computer science and programming language design for surface syntax that improves readability or writability but does not increase what programs can express; the term was coined by Peter J. Landin in 1964. According to Landin’s early work on lambda-calculus-based language design, such sugar can be defined semantically in terms of the underlying calculus and systematically eliminated, leaving expressiveness unchanged. The Computer Journal; Communications of the ACM.

Definition and rationale

A language feature is called syntactic sugar if it can be removed (via mechanical translation) without changing the set of programs the language can express; its purpose is human convenience rather than new computational capability. This understanding is standard in language texts and reference materials and traces to Landin’s distinction between a small “core” and sugared surface forms. The Computer Journal; Communications of the ACM.

Desugaring is often an explicit phase in a compiler or interpreter: the front end rewrites sugared syntax to a core language before later analysis or code generation. Modern research formalizes such rewritings and their correctness so that sugar does not “leak” abstraction. Proceedings of the ACM on Programming Languages.

Origins and historical context

Landin introduced the metaphor to articulate how practical, ALGOL-like notations could be grounded in lambda calculus while remaining pleasant for programmers; his ISWIM framework described “a syntactic sugaring of lambda calculus” enriched with imperative features. Communications of the ACM; Wikipedia: ISWIM (cites Landin 1966).

Building on Landin’s core/sugar distinction, Felleisen proposed a formal notion of expressiveness in which a construct is “more expressive” only if removing it would force a substantial reorganization of programs—clarifying that sugar, by definition, should not change expressive power. Science of Computer Programming; Springer LNCS (ESOP 1990).

Typical examples and desugarings

• –Haskell list comprehensions provide a compact notation that the language report specifies as a translation to core higher-order functions such as concatMap and conditionals, making them canonical syntactic sugar. Haskell 98 Report §3.11; Haskell 98 (mirror).
• –In C, the array subscript expression E1[E2](/search?q=E2&internal=true) is defined by the standard to be identical to *((E1)+(E2)), so bracket indexing is sugar for pointer arithmetic and indirection. ISO/IEC C99 draft N843 §6.5.2.1.
• –In C#, the using statement is specified to expand to a try/finally form that disposes the resource, illustrating a sugared control structure. Microsoft Learn: C# language specification — using statement; Microsoft Learn: exception handling.
• –In Python (and many languages), decorator syntax is defined as shorthand for rebinding a function to the result of calling decorator(s) on it, e.g., @d1; @d2; def f(): ... is equivalent to f = d1(d2(f)). PEP 318.

These examples show how sugared forms are systematically rewritten into a core, supporting tooling, analysis and optimization without requiring the core to expose the sugared notations. Haskell 98 Report §3.11; ISO/IEC C99 draft N843; Microsoft Learn; PEP 318.

Sugar, macros, and language extension

Sugar is frequently introduced or customized by macro systems, which expand user-defined syntactic forms to core language constructs while preserving hygiene and scope. Contemporary systems illustrate how libraries can carry syntactic extensions and how hygienic expansion avoids name capture. OOPSLA 2011 (SugarJ); Sweet.js.

Macro-based sugar is conceptually distinct from adding new semantics: in hygienic macro systems (e.g., Scheme/Racket descendants), macro expansion produces core-language programs whose meaning is determined by the underlying evaluator, keeping sugar at the syntactic layer. OOPSLA 2011 (SugarJ); Sweet.js docs.

Critiques and derivative terms

The presence of extensive sugar can complicate a specification or tooling and sometimes obscures data flow; this concern is longstanding in communities favoring small uniform cores. A well-known quip by Alan Perlis captures a critical stance: “Syntactic sugar causes cancer of the semicolon.” ACM SIGPLAN Notices 17(9), 1982; Yale CS page.

Related coinages include “syntactic salt” (features that intentionally make certain code harder to write) and “syntactic saccharin/syrup” (pejoratives for gratuitous or unhelpful sugar); these terms are tracked in community glossaries. The Jargon File.

Relationship to expressiveness and cores

By definition, sugar does not alter a language’s expressive power; it shortens or clarifies programs that could already be written. Formal criteria for expressiveness (e.g., Felleisen’s) distinguish such convenience from constructs that genuinely enable new program organizations that cannot be obtained by local, semantics-preserving rewritings. Science of Computer Programming; Springer LNCS (ESOP 1990).

In practice, many language designs are presented as a small core plus a sugared surface that programmers use, improving ergonomics while preserving a tractable semantic basis for reasoning and implementation. Communications of the ACM; Proceedings of the ACM on Programming Languages.

See also and connections

Syntactic sugar often appears alongside topics such as [macro (computer science)], core calculi for lambda calculus, and surface features in languages like Haskell, [Python (programming language)], and [C (programming language)], each of which specifies translations to a core as part of its definition or tooling. Haskell 98 Report §3.11; PEP 318; ISO/IEC C99 draft N843.