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. 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, in the Python programming language it is possible to get a list element at a given index using the syntax list_variable.__getitem__(index), but this is frequently shortened to list_variable[index] which could be considered simpler and easier to read, despite having identical behavior. Similarly, list_variable.__setitem__(index, value) is frequently shortened to list_variable[index] = value.

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: functionality and expressive power will remain the same.

Language processors, including compilers and static analyzers, often expand sugared constructs into their more verbose equivalents before processing, a process sometimes called "desugaring".

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,^[1][2] centered on lexically replacing λ with "where".

Later programming languages, such as CLU, 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.^[3] This is, in fact, the usual mathematical practice of building up from primitives.

ランディンの言語の本質的な構成要素と構文糖衣の区別に基づいて、1991年にマティアス・フェライゼンは、文献における「広く受け入れられている信念」に沿うように「表現力」の体系化を提案した。彼は「より表現力がある」とは、問題となっている言語構成要素がなければ、プログラムを完全に再編成する必要があることを意味すると定義した。^{[ 4 ]}

• COBOLでは、多くの中間キーワードは構文糖衣であり、省略することも可能です。例えば、 と はMOVE A B.全くMOVE A TO B.同じ機能を果たしますが、後者の方が実行される動作がより明確になります。
• Perlでは、は の構文糖衣です。さらに、任意のステートメントの後には条件が続くため、 は と同等ですが、前者の方が 1 行でより自然にフォーマットされます。unless(condition){...}if(notcondition){...}statementifconditionif(condition){...}
• C 言語では、a[i]表記は の構文糖衣です*(a + i)。^{[ 5 ]}同様に、表記は、参照解除演算子を使用してメンバーにアクセスするa->xための構文糖衣です。(*a).x
• C#usingのステートメントは、特定のオブジェクトが正しく破棄されることを保証します。コンパイラはステートメントをtry-finallyブロックに展開します。^{[ 6 ]}
• C++およびC23以降のCでは、C++ またはC の省略形として使用できます。auto x = exprdecltype(expr) x = exprtypeof(expr) x = expr
• Python のリスト内包表記(正方形のリストなど) とデコレータ(など)。[x*xforxinrange(10)]@staticmethod
• Haskellでは、引用符で囲まれた文字列は、意味的には文字のリストと同等です。オプションの言語拡張機能OverloadedStringsを使用すると、文字列リテラルからTextなどの他の型の値も生成できます。
• tidyverse Rパッケージのコレクションでは、パイプは で表され、%>%パイプの前にあるデータ (または関数の出力) が、パイプの後に続く関数の最初の引数として使用されることを宣言します。^{[ 7 ]}したがって、 はと同等です。x %>% f(y)f(x,y)
• SQLでは、単なるJOINは と同等でありINNER JOIN、後者は、結合ステートメントが外部結合操作ではなく、内部結合操作であることを明確化します。同様に、 、およびからOUTERを省略できます。LEFT OUTER JOINRIGHT OUTER JOINFULL OUTER JOIN
• オブジェクト指向言語における拡張メソッドはmyObject.myMethod(parameter1, parameter2, parameter3)、グローバル関数をとして呼び出すための構文糖衣です。オブジェクトへの参照は、通常メソッド内からとしてアクセスできる隠し引数として渡されます。myMethod(myObject, parameter1, parameter2, parameter3)this
• 参照渡しされるパラメータは、技術的にはポインタをパラメータとして渡すものの、構文的には変数自体として扱うための構文糖衣であり、関数内のコードでポインタの参照解除が頻繁に行われるのを避けるためのものです。
• 様々なプログラミング言語には、別の名前空間からシンボルを現在のスコープに 追加できるようにするimport文が用意されています。
  • C++では、usingステートメントは単一のシンボルをスコープにインポートする例であり、using namespace名前空間はその名前空間内のすべてのシンボルをスコープにインポートします。
  • C#では、usingステートメントによって名前空間内のすべてのシンボルがスコープに追加されます。
  • Javaでは、 はimportその一例です。たとえば、を使用するとimport javax.swing.*;、プログラマーはという名前だけでSwingオブジェクトを参照できます。javax.swing.JButtonJButton
  • Pythonでは、` from importimport`文は単一のシンボルをスコープにインポートしますが、` from import *import`文はその名前空間のすべてのシンボルをスコープにインポートします。
  • Rustでは、useスコープにシンボルをインポートするためにステートメントが使用されます。
• JavaScriptでは、オブジェクト内のキーと値が同じ場合、一度だけ記述すれば済みます。例えば、{name: name}は と同等です{name}。これは短縮形プロパティと呼ばれます。
  • JavaScriptのES6バージョンでは、アロー関数には短縮形があり、これは長い形式と同等です。(x) => x + 1(x)=>{returnx+1;}
• Scalaでは、3 つの疑問符 ( ???) は と同等です。これは、まだ書かれていないコードの場所を示すのに便利です。^{[ 8 ]}thrownewscala.NotImplementedError("an implementation is missing")

プログラマーの中には、こうした構文の使いやすさに関する機能は重要でないか、あるいは全く無意味だと感じる人もいます。特に、特殊な構文形式は言語の統一性を損ない、仕様を複雑にし、プログラムが大規模かつ複雑になるにつれて問題を引き起こす可能性があります。この見解は、 Lisp のコミュニティで特に広く見られます。Lisp は非常にシンプルで規則的な構文を持ち、表面的な構文は簡単に変更できるからです。^{[ 9 ]} 例えば、アラン・パーリスはかつて「プログラミングに関する警句」の中で、括弧で区切られた言語に言及して、「構文糖衣はセミコロンの癌を引き起こす」と皮肉を言いました。^{[ 10 ]}