回答:
これについてはどうですか：「構文糖は、意味のある抽象化レイヤーを導入しない一部の機能の便利な省略表現です。」
テイクa->bあなたが指摘するように、と等価です、、 (*a).b。この表記は、それが有用であるか、そうでなければ隠されている方法でコードを検討することを可能にしますか？いいえ、そのため、これは構文糖です。
今考えなさいa[i] == *(a + i)。実質的な方法で配列を使用するCプログラムについて考えてみてください。[]表記なしでそれを理解しようとすることを想像できますか？多次元配列では？配列を連続したメモリブロックの開始への参照としてではなく、ユニット全体として考えることは重要です。複雑な処理を計画している場合は、配列がCでどのように機能するかを知るのに役立ちますが、「2ビットのメモリ2 * iバイトを、によって参照されるメモリ位置a。」配列の要点は、シーケンスを一貫性のある単位として格納するプロセスを抽象化する機能です。[]表記は、この抽象化を容易にします。それは構文上の砂糖ではありません。
これは、構文糖が常に悪いことを意味するものではありません。多くの異音化と同様に、それは代名詞になり、「本当の特徴」に対抗しています。しかし、たとえばLISPとSchemeは、let省略形（およびその他）でないと読めません。
三項演算子<pred> ? <cnsq> : <alt>は別の例です。シンタックスシュガーは、プログラムを整理し、冗長なコードを削除するのに役立ちます。これにより、メンテナンスを減らすことができます。プログラミングの構文上の障壁を取り除くのに役立つ場合は、「実際の機能」を積み上げるよりも、構文上の砂糖の方が好ましい場合があります。
R ^ 5RSを引用すると、「プログラミング言語は、機能を機能の上に積み上げることではなく、追加の機能が必要に見えるようにする弱点と制限を取り除くことによって設計されるべきです。」私見、構文は弱点と制限とみなすことができるため、プログラマーが構文を回避できるようにすると、言語の表現力が高まります。
私見私はあなたが構文糖の定義を持つことができないと思います、なぜならフレーズはBSであり、「実際のオペレーティングシステム」で「実際のツール」を使って「実際のプログラマー」について話す人々によって使用される可能性が高いからです
「実際の機能」または「構文上の砂糖」の概念は、真のスコットランド人の誤解に似ているため、そのBSです。そのフレーズは「不当な主張を保持するための臨時の試み」です。ここでの主張は、「実際の機能」を代わりに使用できるため、ここの機能は取るに足らないものであるということです。
バグを書くことができるので砂糖の使用は避けるべきだと主張する人もいるので、そのBS はバグを書くのが難しいので、それに固執する必要があります。それは素晴らしいことではありません。同じフレーズは、同じロジックを使用して、まったく反対の結論を導きます。
そのBSは、ユーザビリティの調査や欠陥の数の調査を誰も引用していないため、それらの可読性や保守性、またはおそらくは欠陥の議論をバックアップするためです。
人々はしばしば等価性について間違っているか間違っているため、そのBS。たとえば、この質問は、C＃文字列がchar配列の砂糖であることを表明しています。彼らはそうではありません。
ただし、意味的に同等である2つのものが砂糖であると言いたい場合、それは先に進み、必要に応じてそれを定義するのに役立ちます。
誰かを非難したい場合は、このフレーズを使用することもできます。
関連する概念の非常に厳密な定義を次に示します。表現力、
Matthias Felleisenによるものです。
プログラミング言語の表現力について [Postscriptは私が見つけた唯一のフリーフォームでした。]
Java言語とクロージャーに関するこのエントリーも参照してください。
事実上、ローカルの変更のみを行うことで構文なしのフォームに変更できる場合、それは構文上の砂糖です。たとえば、構文形式がなければ、いくつかの異なるコードの場所を変更したり、フラグメントを他の場所に移動したりする必要がある場合、それは砂糖ではありません。
そうは言っても、適切に使用すれば構文糖は問題ありません。Schemeのプログラマーはlet、新しい無名関数を作成してから適用するのではなく、同じことをするというよりも、特別な形式が必要だと思います。目的はコードをより明確にすることです。
構文糖という用語は、同じ基本的なセマンティクスを表現するための代替構文を示すと思います。
たとえば、sum任意の長さの整数のリストを追加できる演算を持つプログラミング言語Aを考えてみましょう。この言語では、式を書くことができます
sum []
sum [3, 4, 5, 1]
sum [2, 7]
結果はそれぞれ0、13、9です。
ここで、sum2つの引数を使用して90％の時間を使用していると認識し、したがって、便宜上、新しい表記法を導入するとします。
2 + 7
これはの構文糖ですsum [2, 7]。
ここで、追加演算がまったくない第2言語Bを取り上げます。私たちは、事業者が好き持たないかもしれない<、=私たちは数字を比較することができますが、する方法の追加番号を。言語Bのリリース2では、構文を使用した新しい追加操作が導入されています
2 + 7
通常どおりに数字を追加します。
言語Aのコンテキストでは、+表記は構文糖衣です（これは、sum [...]表記法の代わりに使用できる代替の簡略化されたアドホック表記法です）。同様に、ホアロンタムの回答で指摘されているように、Cでは表記p->fieldはの構文糖です(*p).field。
言語Bのコンテキストでは、+表記は構文糖ではありません（これは、合計演算に使用される唯一の有効な構文です）。同様に、Cがポインタを通じて構造体メンバーにのみアクセスでき(*p).field、表記p->fieldがなかった場合、その表記は構文糖ではありません。
私の意見では、プログラミング言語のセマンティクスに関する混乱にさかのぼることができる構文糖についてのいくつかの誤解があります。推論は次のようになります：
上記の推論は、「構文上のシュガーを適切に定義できない」、「好みの問題」、「結局のところ、すべてのプログラミング言語の機能は構文上のシュガーである」などの一般的な主張につながります。
上記の議論の主な問題は、セマンティクスがプログラムで計算できるものだけでなく、それがどのように計算されるか、つまり使用されるプリミティブコンストラクトとそれらがどのように結合されるかということでもあると思います。
したがって、たとえば、オブジェクトは基本的なビット構成とビット変換の構文糖ではなく、データと操作のモデル化と計算の記述を可能にする構造です。オブジェクト、メソッド、メソッド呼び出しを使用した計算は、バイト、プロセッサレジスタ、メモリアドレスを使用した計算とは異なります（2つの計算の結果が同じでも、2番目の計算を使用して最初の計算を実装しても）。
この説明は少し長くしましたが、他の回答で取り上げられていない重要な側面だと思います。
結論：シンタックスシュガーは、すでに言語に含まれていて、明確に定義された構文とセマンティクスを備えた構成の代替（おそらくより便利な）構文です。新しい構文（構文シュガー）は既存の構文とは異なりますが、セマンティクスは同じです。言語の新しい構成とその新しい構文を導入する場合、構文糖はありません。
自分の質問に答えるために、機能があればシンタックスシュガーであり、それが美学と読みやすさを向上させるために主に含まれていた場合にのみ、そして自明脱糖版におよそ1対1の方式で翻訳することができます。（ほぼ1対1とは、可換演算の順序、変数名、空白などの簡単なことを意味します。）
かなりの量のプログラマの規律によってのみ砂糖を取り除くことができる機能は、構文上の砂糖ではありません。これのサブセットとして、プログラマーの規律を介してタイプセーフティを手動で強制することは非常に簡単ではないため、タイプセーフティを向上させる機能は構文糖質ではありません。たとえば、C ++のオブジェクトシステムは、Cポインターキャストのポリモーフィズムに加えて、単なる構文上の糖衣ではありません。
大幅なコードの複製または削除した場合の大幅な再設計のいずれかを必要とする機能は、構文上の砂糖ではありません。これらはどちらも簡単な作業ではないためです。たとえば、テンプレートを使用せずに同等の機能を取得するには、大量の複製と変更が必要になるため、テンプレートは単なる構文上の砂糖ではありません。
物事の例ですシンタックスシュガー：
a[i] の代わりに *(a + i)
a -> b の代わりに (*a).b
foreach イテレータ構文を手動で入力する代わりに構文。
演算子のオーバーロードはすべて純粋な構文上の砂糖です。
これは公平で合理的に明確な定義のように聞こえますか？
「構文上の砂糖」は厳密に定義された用語ではありません。誰に尋ねるかに応じて、次のような定義のいずれかを取得する可能性が最も高くなります。
コンピュータサイエンスの分野についてはよくわかりませんが、ロジックの分野では、定義の保守性と排除可能性の概念があります[ 1 ]も同じように見えます。
カレーとハワードの対応を適用すると、「構文上の砂糖」に関する並列の概念を思い付くことができるかもしれません。