「有名な論理学者はここで恥ずかしいエラーを犯しました」と、SICPの行。これは何を指しているのですか？

コンテキストは次のとおりです（コンピュータープログラムの構造と解釈、セクション1.1.8、「ローカル名」という見出しの下）。

プロシージャの仮パラメータは、仮パラメータの名前が何であるかは関係ないという点で、プロシージャ定義において非常に特別な役割を果たします。このような名前はバインド変数と呼ばれ、プロシージャ定義はその仮パラメータをバインドすると言います。バインドされた変数の名前が定義全体で一貫して変更されている場合、プロシージャ定義の意味は変わりません。

その最後の行の最後に、脚注（26）があります。

一貫した名前変更の概念は実際には微妙であり、正式に定義するのは困難です。有名な論理学者はここで恥ずかしいエラーを犯しました。

テキストは何を指しているのですか？「一貫性のある名前の変更」を定義するのが難しいのはなぜですか、どの論理学者がこれを定義しようとしてエラーを犯しましたか？

logic

— ubadub
ソース

生徒に、「バインドされた変数の名前を一貫して変更する」ことを理解する唯一の方法は、いまいましいことを正しく実装することだと言います。多くのロジックブックでは、この問題を回避し、名前の変更手順が不完全であるか、少なくとも指定された名前の変更手順が正しいという証拠を省略します。しかし、本がどの特定のゴシップを指しているのかわかりません。

— アンドレイバウアー

変数の名前の変更、新しい名前、キャプチャ回避の置換などを正確に処理することは、定義と証明がすぐに面倒になる最も些細なことの1つです。このような些細な問題については、些細な量の精神サイクル以上を費やすことは望みませんが、多くのトリッキーな捕獲/衝突などを避けるために必要なものよりもはるかに多くのことを望みます。ただし、「Barendregt規約」を呼び出して問題を無視し、必要に応じて「フレッシュ」をあちこちで乱用します。

— チー

可能な場合は、以下の回答ボックスで、より具体的な回答をお願いします。私はないです一方、これらのコメントはまだ、あなたがすでに手元にある問題に精通している人が読むことにそれらを書かれているような問題音が神秘作る

— ubadub

特に@chiは、もしあれば、このトピックを扱った推奨事項を読んでいただければ幸いです。事前に感謝

— ubadub

これは部分的な答えです。SICPが参照しているエラーや人についてはわかりません。「なぜ」変数の名前変更が正確に処理するのが苦痛なのかについて、いくつかのヒントしか提供できません。

まず第一に、定義するのは簡単に思えます。たとえば、インデックス付き合計のバインド変数の名前を変更できます

\sum_{x} e = \sum_{y} (e {y / x})

$\sum_x e = \sum_y (e\{y/x\})$

ここで、 $e$ は任意の式であり、 $e\{y/x\}$ は各 $x$ を $y$ で構文的に置き換えることを示します。簡単ですね

さて、盲目的に上記のルールを適用すると、

\sum_{x} (x + y) = \sum_{y} (y + y)

$\sum_x (x+y) = \sum_y (y+y)$

それは良いことではありません。「 $y$ が $e$ 出現しない」という要件を追加する必要があります。そうしないと、名前の衝突が発生します。

さて、この正しい名前の変更を検討してください

\sum_{バツ} \sum_{y} （ バツ + y ） = \sum_{バツ} \sum_{z} （ バツ + z ）

$\sum_x \sum_y (x+y) = \sum_x \sum_z (x+z)$

私たちは、名前を変更したい場合は $x$ へ $y$ 、上記のルールにより、右側ではできますが、左側ではできません。この2つは名前の変更のみが異なるため、不便です。したがって、同じ方法で処理する必要があります。

ここで典型的なアプローチは、再定義に頼ることである $e\{y/x\}$ 「捕獲回避置換」として、及び要件を緩和「 $y$ 発生しません $e$ 」「代わりに使用 $y$ 発生しないフリーで $e$ 」。

次に、フリーオカレンスを定義します。

f r e e （ バツ ） = {バツ} f r e e （ e + t ） = f r e e （ e ） \cup f r e e （ t ） f r e e （ \sum_{バツ} e ） = f r e e （ e ） ∖ {バツ}

$free(x)=\{x\} \qquad free(e+t) = free(e)\cup free(t) \qquad free(\sum_x e) = free(e)\setminus\{x\}$

最後に、置換を回避してキャプチャします。

$x\{t/y\}$ である $t$ 場合に $x=y$ 、および $x$ そうでありません。
$(e+e')\{t/y\} = e\{t/y\} + e'\{t/y\}$ （簡単な場合）
$(\sum_x e)\{t/y\} = ??$

最後のケースは苦痛です。 $x=y$ 場合、自由変数のみに影響を与え、 $x$ がバインドされているため、置換は何も行われません。結果は $\sum_x e$ 。

$y\neq x$ 場合、 $(\sum_x e)\{t/y\} = \sum_x (e\{t/y\})$ と言います。ただし、これは一般に間違っています $x$ が $t$ フリーになると、キャプチャが取得されるためです。

$z$ $y$ $t$ $\sum_x e$ $(\sum_x e)\{t/y\} = \sum_z (e\{z/x\}\{t/y\})$

私はそれが正しかったと思います。（ちなみに、私の最初の試みは間違っていました）

$z$ $z$ は正常に機能し、同じ結果になります（再び、名前の変更まで）。

$\alpha$ $\lambda x$ 、多くのPLにラムダ計算では、関数の定義など）。

さて、PL理論で何かを証明するたびに、この複雑な定義に対処しなければならないことを想像してください。できましたが、したくありません。退屈で退屈でエラーが発生しやすく、証拠が乱雑であり、読者に洞察を与えません。このため、多くのPL作成者は、用語は「変数名の変更」までと見なされ、バインドされたすべての変数は区別する必要があるものとは異なるものと見なされると言う（または当然のこととして！）「Barendregtの慣習」、または同じ効果を持つ何かを想定していること。

ひどく正直に言うと、これは証拠にだまされています。「ウインクウインク、ナッジナッジ、ノーマイン！」を追加することもできます。同じ精神で。私たちは本質的に慈悲を求め、読者に言います：「見て、これは退屈だ、私はそれをしたくない、あなたはそれを読みたくない-私たちは両方とも、多大な努力で、この証明をすべての詳細を含める」。

技術的には、このショートカットを悪用して虚偽の陳述を証明することができます。しかし、経験豊富な証明レビューアは、「道徳的に素晴らしい」ものを知っており、（多大な努力を払って）完璧に仕上げることができ、何が疑わしいのか。後者には、バインドされた名前の実際の選択に依存するものが含まれる可能性があります（つまり、約束どおりに「最大」で動作していません！）。そのような場合、レビューはより詳細な情報を要求するため、納得することができます。

— チー
ソース