チャールズの答えに基づいて、プログラミング言語の理論の主な難しさは、プログラムの等価性の自然な概念は、通常、与えることができる最も単純な数学的意味論または基礎となる機械モデルのいずれにおいても厳密な平等ではないということです。たとえば、次のJavaのようなコードを考えてみましょう。
Object x = new Object();
Object y = new Object();
... some more code ...
したがって、このプログラムはオブジェクトを作成してxという名前を付け、次にyという名前の2番目のオブジェクトを作成してから、さらにコードの実行を続けます。ここで、プログラマーがこれら2つのオブジェクトの割り当ての順序を逆にすることにしたと仮定します。
Object y = new Object();
Object x = new Object();
... some more code ...
次に、質問をします。このリファクタリングはプログラムの動作を変更しますか?一方では、基礎となるマシンでは、xとyはプログラムの2つの実行の異なる場所に割り当てられます。この意味で、プログラムの動作は異なります。
しかし、Javaライクな言語では、参照をテストすることができるのは順序だけではなく、等しいかどうかだけです。したがって、これは「もう少しコード」が観察できない違いです。その結果、ほとんどのプログラマーは順序を逆にしても最終的な答えに違いはないと予想し、ほとんどのコンパイラー作成者はこれに基づいて並べ替えと最適化を実行できると期待します。(一方、Cライクな言語では、最初に整数にキャストすることで、ポインターを並べ替えて比較することができます。したがって、この並べ替えは必ずしも観察可能な動作を保持しません。)
セマンティクスの中心的な質問の1つは、2つのプログラムが明らかに同等である場合の質問に答えることです。観察の概念はプログラミング言語の機能に依存するため、「クライアントプログラムが入力としてそれらのプログラムを受信することに基づいて異なる回答を計算できない場合、2つのプログラムは同等です」という定義になります。すべてのクライアントプログラムの定量化がこの質問を難しくしているのです。特定の2つのコードについて何かを言うには、考えられるすべてのクライアントプログラムについて何かを言わなければならないようです。
表示的セマンティクスのトリックは、この普遍的な数量化を避けることができる数学的な解釈を与えることです-コードの一部の意味は数学的な値であると言い、それらが数学的に等しいかどうかをチェックして比較しますありません。これはローカル(つまり、構成的)であり、可能なすべてのクライアントに対する定量化は含まれません。(もちろん、意味論的意味論は、それが健全であるための文脈的等価性を意味することを示す必要があります。
しかし、意味論的意味論がそれらの等価性を検証することを保証する必要があることを意味します。したがって、この例では、このJavaライクな言語に表示的なセマンティクスを与えたい場合、newを呼び出すとヒープが取得され、新しく作成されたオブジェクトで新しいヒープが返されるだけでなく、プログラムのすべては、入力ヒープのすべての順列で同じ不変です。これには、非常に複雑な数学的構造が含まれる可能性があります(たとえば、この場合、すべてが適切な順列グループを法として機能することを保証するカテゴリで動作します)。