"Lógicos famosos cometeram erros embaraçosos aqui", uma linha do SICP. A que isso se refere?

Aqui está o contexto ( Estrutura e Interpretação de Programas de Computador , seção 1.1.8, sob o título "Nomes locais"):

Um parâmetro formal de um procedimento tem um papel muito especial na definição do procedimento, pois não importa qual o nome do parâmetro formal. Esse nome é chamado de variável vinculada e dizemos que a definição do procedimento liga seus parâmetros formais. O significado de uma definição de procedimento é inalterado se uma variável vinculada for renomeada consistentemente em toda a definição.

No final dessa última linha, há uma nota de rodapé (26), que diz:

O conceito de renomeação consistente é realmente sutil e difícil de definir formalmente. Lógicos famosos cometeram erros embaraçosos aqui.

A que ou a quem o texto se refere? Por que seria difícil definir "renomeação consistente", quais lógicos cometeram erros ao tentar definir isso e quais eram esses erros?

logic

— ubadub
fonte

Eu digo aos meus alunos que a única maneira de entender "renomear consistentemente variáveis vinculadas" é implementar a maldita coisa corretamente. Muitos livros de lógica evitam o problema, fornecem procedimentos de renomeação incompletos ou, no mínimo, omitem provas de que os procedimentos de renomeação fornecidos estão corretos. Mas não sei a que fofoca específica o livro se refere.

— Andrej Bauer

Lidar com precisão com renomeação de variáveis, nomes novos, substituição para evitar capturas e similares é uma das coisas mais triviais que rapidamente se torna realmente complicada em definições e provas. Para uma questão tão trivial, não se deseja gastar mais do que uma quantidade trivial de ciclos mentais, mas muito mais do que isso seria necessário para evitar muitas capturas / colisões / etc. complicadas. definições, mas depois invoque a "convenção de Barendregt" e ignore o problema, abusando um pouco de "novo" aqui e ali, quando necessário.

— chi

Eu apreciaria respostas mais concretas, abaixo na caixa de respostas, se possível. Esses comentários ainda fazem o problema parecer misterioso, pois você os escreveu para serem lidos por alguém que já está familiarizado com o problema em questão, enquanto eu não sou.

— ubadub

@chi em particular, eu gostaria de ler recomendações que abordem esse tópico, se você tiver algum. Agradecemos antecipadamente

— ubadub 23/09/18

Esta é uma resposta parcial: não tenho idéia sobre a quais erros ou pessoas o SICP está se referindo. Só posso fornecer algumas dicas sobre "por que" renomear variáveis pode ser doloroso de lidar com precisão.

Antes de tudo, parece trivial definir. Por exemplo, podemos renomear variáveis vinculadas em somas indexadas

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

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

onde $e$ é qualquer expressão e $e\{y/x\}$ denota a substituição sintática de cada $x$ por $y$ . Trivial, certo?

Bem, se aplicarmos cegamente a regra acima, obtemos

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

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

Isso não é bom. Precisamos adicionar o requisito " $y$ não ocorre em $e$ " ou temos um conflito de nome.

Agora, considere esta renomeação correta

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

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

se queremos renomear $x$ em $y$

Uma abordagem típica aqui é recorrer à redefinição de $e\{y/x\}$ como "substituição que evita a captura" e relaxar o requisito " $y$ não ocorre em $e$ " e, em vez disso, usar " $y$ não ocorre livre em $e$

Em seguida, definimos ocorrências livres:

f r e e (x) = {x} f r e e (e + t) = f r e e (e) \cup f r e e (t) f r e e (\sum_{x} e) = f r e e (e) ∖ {x}

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

Por fim, capture evitando a substituição:

$x\{t/y\}$ $t$ $x=y$ $x$ de outra forma.
$(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\})$

Espero ter acertado. (Minha primeira tentativa estava errada, a propósito)

$z$ $z$ funcionaria bem e levaria ao mesmo resultado (novamente, até renomear).

$\alpha$ $\lambda x$ no cálculo lambda, definições de funções em muitos PLs, etc.).

Agora, imagine ter que lidar com essa definição complexa toda vez que quisermos provar algo na teoria da PL. Poderíamos, mas não queremos. É chato, tedioso, propenso a erros, atravessa a prova e não fornece informações ao leitor. Por esse motivo, muitos autores de PL simplesmente ignoram os detalhes dizendo (ou mesmo aceitando!) Que os termos devem ser considerados "até a renomeação de variáveis", que todas as variáveis vinculadas são assumidas distintas daquilo que precisam ser distintas, que assumimos a "convenção Barendregt", ou algo do mesmo efeito.

Para ser brutalmente honesto, isso é trapaça nas provas. Também poderíamos adicionar "piscadela piscadela, nudge nudge, não diga mais nada!" no mesmo espírito. Essencialmente, pedimos misericórdia e dizemos ao leitor: "olha, isso é chato, eu não quero fazer isso, você não quer ler - nós dois sabemos que, com um grande esforço, poderíamos reescrever essa prova para inclua todos os detalhes ".

Tecnicamente, é possível explorar esse atalho para provar uma declaração falsa. O revisor experiente, no entanto, sabe o que é "moralmente bom" e pode ser aperfeiçoado (com grande esforço) e o que é suspeito. O último pode incluir algo que depende da escolha real dos nomes de limite (portanto, não estamos realmente trabalhando "de acordo com o prometido!). Nesses casos, a revisão solicitará mais detalhes, para que ele possa ser convencido.

— chi
fonte