「Syntax」と「Syntactic Sugar」の違いは何ですか

バックグラウンド

Syntactic SugarのWikipediaページには次のように記載されています。

コンピューターサイエンスでは、構文シュガーは、読みやすく、表現しやすいように設計されたプログラミング言語内の構文です。これにより、人間が使用する言語が「より甘く」なります。物事をより明確に、より簡潔に、または一部の人が好む代替スタイルで表現できます。

私は、Syntactic SugarとSyntaxの違いが本当に理解できません。

私は、甘いバージョンがより明確で簡潔になり、おそらくいくつかの定型的なものがなくなる可能性があるという点に感謝します。しかし、ある程度のレベルでは、すべての構文が本質的にそれを行って、コードがコンパイルされるものを抽象化することを感じています。

同じウィキペディアのページから：

コンパイラー、静的アナライザーなどを含む言語プロセッサーは、しばしば「デシュガー化」と呼ばれるプロセスの前に、シュガー化されたコンストラクトをより基本的なコンストラクトに拡張します。

思考演習として、このステートメントで「頻繁に」「常に」を意味する場合：コンパイラが次の段階に進む前に構文を「デシュガー」するかどうかだけでは、内臓を知らないコーダーはコンパイラの何がSugar'd Syntaxとは何かを知っている（または気にしている）？

このサイトに関する非常に関連した質問「構文糖の厳密な定義？」始まる答えがあります：

私見私はあなたがフレーズがBSであり、「本当のオペレーティングシステム」で「本当のツール」を使用して「本当のプログラマー」について話す人々によって使用される可能性が高いので、構文糖の定義を持つことができるとは思わない

おそらく、この言語を使用しているコーダーに大きな違いはないことを私に示すかもしれません。おそらく、違いはコンパイラの作者にしか認識できないのでしょうか？言語を使用するコーダーがSyntactic Sugarの内部にあるものを知ることが役立つ場合がありますか？（しかし、実際には、主題に関するどんな言説でも、炎の餌としてこの用語を使用する傾向がありますか？）

質問の核心

だから...質問の短いバージョン：

• SyntaxとSyntactic Sugarの間に本当の違いはありますか？
• 誰が重要ですか？

思考のための余分な食べ物

トピックの矛盾に関するボーナス：

ウィキペディアのページに例を示します。

たとえば、C言語では、a[i]表記法は*(a + i)

上記のリンクされた質問に関する別の答えは、同じ例について語っています：

考えてみてくださいa[i] == *(a + i)。実質的な方法で配列を使用するCプログラムについて考えてください。

そしてそれを要約します：

[]表記は、この抽象化を容易にします。構文糖衣ではありません。

同じ例の反対の結論！

主な違いは、構文は言語で定義された文法であり、いくつかの機能を公開できることです。その機能に到達できるとすぐに、同じことを実行できる他の構文はすべて砂糖と見なされます。それはもちろん、2つの構文のどちらが糖であるかについて奇妙なシナリオにぶつかります。特に、どちらが最初に来たのかが常に明確ではないためです。

実際には、構文糖は、中にinfix lhs + rhsmapを作成するなど、使いやすさを促進するために言語に追加された構文を記述するためにのみ使用されますlhs.Add(rhs)。私はCの配列のインデックス付けは構文糖とみなします。

エレガントなデザインが複製の量を制限する傾向があるため、それは主に重要です。シンタックスシュガーが必要な（または少なくとも欲しがる）ことは、デザインが失敗する兆候と見られる人もいます。

構文は、言語プロセッサが言語の構成要素の意味を理解するために使用するものです。構文糖とみなされる構成体も言語プロセッサによって解釈される必要があるため、言語構文の一部です。

構文シュガーを言語の残りの構文と区別するのは、その言語で記述できるプログラムに影響を与えることなく、言語から構文シュガーを削除できるということです。

より形式的な定義を与えるために、私は言うだろう

構文糖は、その効果が言語の他の構文構成要素によって定義される言語の構文の部分です。

構文糖を使用すると、意図がより理解しやすいプログラムになることが多いため、これは構文糖またはそれを使用する言語を中傷することを意味するものではありません。

他の回答では、主要な概念に言及していません： 抽象構文 ; それなしでは、「構文糖」という用語は意味をなしません。

抽象構文は、言語の要素と構造を定義し、その言語のフレーズを組み合わせてより大きなフレーズを作成する方法を定義します。抽象構文は、具体的な構文とは無関係です。「構文糖」という用語は、私が理解しているように、具体的な構文を指します。

一般に、言語を設計するときは、抽象構文の各用語に対して具体的な構文を作成して、プレーンテキストを使用して言語でコードを記述できるようにします。

ここで、fooの扱いにくい具体的な構文を作成するとします。ユーザーから苦情があり、同じ抽象構文を表す新しい具体的な構文を実装します。その結果、抽象構文とセマンティクスは変更されていませんが、同じ抽象構文用語に対して2つの具体的な構文があります。

これは、人々が「構文糖」と言うときの意味であると思います。具体的な構文にのみ影響するが、抽象的な構文やセマンティクスには影響しない変更です。

したがって、「構文糖」と「具体的な構文」の違いは明確になりました。私に。:)

この解釈はまた、アランペルリスが「シンタクティックシュガーがセミコロンの癌を引き起こす」と言ったときの意味を説明するのに役立ちます。実際の問題である抽象構文に対処するために費やしていない努力。

また、これは単に私の意見です。それは私が考えることができる唯一の解釈であり、私にとって理にかなっているからです。

構文糖は、言語構文のサブセットです。基本的な考え方は、同じことを言うには複数の方法があるということです。

何が落札困難シンタックスシュガーであり、その作品は「純粋な構文」ですそれはだ」または「それは言語の作者が意図した方法を知るのは難しい」または「それは、フォームが最初に来たと言うのは難しい」のような文である作品と言うことどのフォームがよりシンプルかを判断するのはややarbitrary意的です」。

何がそれを作る簡単に特定のコンパイラやインタプリタの枠内で質問をするために、純粋なまたは甘いですされている作品を決定します。純粋な構文とは、コンパイラがマシンコードに直接変換するもの、またはインタープリターが直接応答するものです。砂糖は、これらの直接的なことが起こる前に最初に他の構文に変換されるものです。実装に応じて、これは、著者が意図したものと、または言語仕様が主張するものと同じである場合とそうでない場合があります。

実際には、これは問題の現実が決定される方法です。

本当に、ウィキペディアからの最初の引用は、「...読みやすくするために...」、「....人間が使用するのにより甘くする...」と言っています。

執筆では、「しない」や「持っていない」などの短縮形は構文糖と見なすことができます。

通常、構文シュガーは言語の一部であり、一般性を失うことなく既存の言語の一部（構文）で表現できますが、明快さを失う可能性があります。コンパイラには、ソースコードによって作成されたASTを変換し、シュガーに対応するノードを削除するための簡単な手順を適用する明示的なデシュガー化ステップがある場合があります。

たとえば、Haskellには再帰的に適用される次のルールを持つモナドの構文シュガーがあります

do { f }            ~> f
do { g; h }         ~> g >> do h
do { x <- f; h }    ~> f >>= \x -> do h
do { let x = f; h } ~> let x = f in do h

今のところ、それが正確に何を意味するかは問題ではありませんが、LHSの特別な構文はRHSのより基本的なもの（つまり、関数アプリケーション、ラムダ、およびlet）に変換できることがわかります。この手順により、両方の長所を維持できます。

1. LHSの構文は、既存のアイデアをより明確に表現するプログラマー（構文糖）にとって簡単です。
2. ただし、RHSコンストラクトに対するコンパイラーのサポートは既にコンパイラーに存在するため、パーサーとデシュガーイング以外の特別なものとして扱う必要はありません（エラー報告を除く）。

同様に、Cでは、脱糖書き換えルールを想像できます（演算子のオーバーロードなどのため、C ++には当てはまりません）。

f->h ~> (*f).h
f[h] ~> *(f + h)

あなたは使用せずに、すべてのプログラムを書いて想像できる->か、[]今日このような構成を使用しCに。しかし、プログラマーがそれを使用することはより困難であり、それゆえ構文シュガーを提供していました（70年代にはコンパイラーの作業も簡略化されると思います）。次の完全に有効な書き換えルールを技術的に追加できるため、あまり明確ではありません。

*f ~> f[0] -- * and [] have the same expressiveness 

構文砂糖は悪いですか？必ずしもではありません-より深い意味を理解せずに貨物カルトとして使用される危険があります。たとえば、次の関数はHaskellでは同等ですが、多くの初心者は構文シュガーを使いすぎていることを理解せずに最初のフォームを記述します。

f1 = do x <- doSomething
        return x
f2 = doSomething

さらに、シンタックスシュガーは、言語を複雑にしすぎたり、一般的な慣用コードを許可するには狭すぎたりする可能性があります。また、特定のことを簡単に行うには言語が十分に強力ではないことを意味する可能性があります-設計による（開発者に鋭いツールや、より強力な構造を追加すると他の目標を損なうような特定のニッチ言語を与えないで）または省略による可能性がありますフォームは構文シュガーに悪い名前を与えました。言語が、構文シュガーを追加せずに他の構成要素を使用するのに十分強力な場合、それらを使用する方がよりエレガントであると考えられます。

最も明白な例は、Cの「+ =」構文だと思います。

i = i + 1;

そして

 i +=  1;

まったく同じことを行い、まったく同じ機械語命令のセットにコンパイルします。2番目の形式では、数文字の入力を節約できますが、さらに重要なことは、現在の値に基づいて値を変更していることを非常に明確にすることです。

標準的な例として「++」ポスト/プレフィックス演算子を引用するつもりでしたが、これは構文上の砂糖以上のものであることに気付きました。i = i + 1構文を使用して単一の式で++ iとi ++の違いを表現する方法はありません。

最初に、他の回答のいくつかを具体的な例で説明します。C ++ 11の範囲ベースのforループ（他のさまざまな言語のforeachループによく似ています）

for (auto value : container) {
    do_something_with(value);
}

（つまり、砂糖バージョン）とまったく同じです

for (auto iterator = begin(container); iterator != end(container); ++iterator) {
    do_something_with(*iterator);
}

現在、新しい抽象構文やセマンティクスを言語に追加していませんが、実際の有用性があります。

最初のバージョンでは、意図（コンテナ内のすべてのアイテムを参照）が明示されます。また、トラバース中にコンテナを変更したりiterator、ループ本体をさらに進めたり、ループ条件を微妙に間違ったりするなどの異常な動作も禁止します。これにより、考えられるバグの原因が回避され、そうすることで、コードの読み取りと推論の難しさが軽減されます。

たとえば、2番目のバージョンでの1文字の間違い：

for (auto iterator = begin(container); iterator <= end(container); ++iterator) {
    do_something_with(*iterator);
}

過去1日のエラーと未定義の動作を提供します。

そのため、砂糖を使用したバージョンはより制限的であり、したがって信頼と理解がより簡単であるため、まさに有用です。

第二に、元の質問へ：

SyntaxとSyntactic Sugarの間に本当の違いはありますか？

いいえ、「構文糖」は（具象）言語構文であり、言語の抽象的な構文またはコア機能を拡張しないため、「砂糖」と見なされます。これに関するマット・フェンウィックの答えが好きです。

誰が重要ですか？

他の構文と同様に、言語のユーザーにとって重要であり、その中で特定のイディオムをサポートする（ある意味祝福する）砂糖が提供されています。

最後に、ボーナス質問について

[]表記は、この抽象化を容易にします。

これは、構文シュガーの定義によく似ています。配列としてポインターを使用することをサポートしています（そして、言語作成者の祝福を提供します）。p[i]フォームは、より実際より制限ではありません*(p+i)ので、唯一の違いは、意図（と若干の読みやすゲイン）の明確なコミュニケーションです。

フレーズの元の意味が何であれ、今日では主に軽jor的であり、ほぼ常に「ジャスト」または「オンリー」の構文糖としてフレーズされています。読み取り不可能な方法で作業を行い、それを同僚に正当化するための簡潔な方法を望んでいるプログラマーにのみ重要なのです。彼らの観点から、今日主にこの用語を使用する人々による定義は次のようになります：

言語を実際に理解していないプログラマーに松葉杖を提供するために、他のより広く適用可能な構文と冗長な構文。

そのため、同じ構文要素に対して2つの反対の結論が得られます。配列表記の最初の例は、Bartの答えに似た用語の元の肯定的な意味を使用することです。2番目の例は、軽jor的な意味での構文糖であるという告発に対する配列表記の防御です。言い換えれば、構文は松葉杖ではなく有用な抽象化であると主張しています。