Dado que a Correspondência Curry-Howard é tão amplamente difundida / estendida, existe alguma diferença entre provas e programas (ou entre proposições e tipos)? Podemos realmente identificá-los?
Dado que a Correspondência Curry-Howard é tão amplamente difundida / estendida, existe alguma diferença entre provas e programas (ou entre proposições e tipos)? Podemos realmente identificá-los?
Respostas:
As linguagens de programação que as pessoas usam no dia a dia não se encaixam tão bem na correspondência de Curry-Howard, porque seus sistemas de tipos são muito fracos. Para dizer algo interessante usando o Curry-Howard para programas imperativos, é preciso ter um sistema de tipos mais sofisticado. O livro Adaptação de Provas como Programas empurra esse ângulo com o objetivo de sintetizar programas imperativos. Com os tipos dependentes se tornando cada vez mais populares, certamente nas linguagens funcionais de pesquisa ( Agda , Epigram ), a distinção está se tornando mais desfocada. Claro que você pode fazer a síntese do programa / extração dentro do Coq teoremas (e presumivelmente outros), que é, naturalmente, com base em Curry-Howard.
A correspondência de Curry-Howard também pode ser usada em situações em que as provas não correspondem tão claramente aos programas (ou não são programas que alguém jamais executou). Um exemplo disso está na autorização de transporte de prova . As proposições correspondem a declarações sobre quem está autorizado a fazer o que. As provas fornecem as evidências necessárias de que uma proposição é válida, portanto, uma solicitação de autorização é permitida. Para codificar as provas, os termos da prova são introduzidos (via Curry-Howard). Os termos da prova são enviados entre as partes como representações das provas da validade dos pedidos de autorização, mas não são considerados programas.
No Coq, existem 2 tipos (Prop e Set), que são usados pelo programador para separar as provas que não produzirão código real e a parte da prova que será usada para extrair o código em execução (seu programa).
Essa é uma boa solução para o problema que você pergunta, como identificar o que significa gerar código de máquina (programa) e o que está presente para concluir a prova da proposição (ou tipo).
AFAIK não existe uma maneira automática de distinguir os dois. Isso pode ser algo interessante para a pesquisa? Ou talvez alguém seja capaz de apontar que é claramente impossível?
Com tipos dependentes, não apenas não há uma distinção clara entre provas e programas, mas também não há distinção entre programas e tipos! A única distinção será onde o tipo (ou programa) aparece, fazendo parte do local "programa" ou do local "tipo" de um determinado termo.
Um exemplo tornará mais claro, espero:
Quando você usa a função de identidade com tipos dependentes, precisa passar o tipo com o qual irá usar a função! O tipo está sendo usado como um valor no seu "programa"!
Cálculo lambda não tipado:
Com tipos dependentes:
id: (A: Conjunto) -> A -> A
Se você estiver usando esta função, faça-o como este exemplo:
id Naturals 1
Observe que o "tipo" (neste caso, o Conjunto de Naturais) sendo passado como um valor é jogado fora, para que nunca seja computado, mas ainda está na parte "programa" do termo. É o que também acontecerá com as partes "de prova", elas precisam estar lá para o termo checar, mas durante o cálculo elas serão jogadas fora.
Vou falar sobre isso aqui e dizer que, se você estiver disposto a apertar um pouco, provas e programas de encerramento podem ser identificados.
Qualquer programa de encerramento é uma prova de que você pode receber sua entrada e produzir sua saída. Este é um tipo muito básico de prova de implicação.
Obviamente, para tornar essa implicação transportar informações mais significativas do que declarar o óbvio, é necessário mostrar que o programa funciona para toda e qualquer instância de entrada desenhada de alguma classe com significado lógico. (E também para a saída.)
Por outro lado, qualquer prova com etapas de inferência finita é um programa simbólico que manipula objetos em algum sistema lógico. (Se não nos preocuparmos muito com o que os símbolos e regras lógicos significam computacionalmente.)
Isso é bastante simplista, mas acho que sugere a robustez da ideia. (Mesmo que algumas pessoas não gostem. ;-))
Prova irrelevância?
Quando você escreve algum programa, está interessado em desempenho, consumo de memória, etc.
Por exemplo, é melhor usar algum algoritmo de classificação inteligente em vez de bolha, mesmo que suas implementações tenham os mesmos tipos (mesmo na configuração de tipo dependente).
Mas quando você prova algum teorema, é apenas a existência de uma prova na qual você está interessado.
Obviamente, do ponto de vista estético, algumas provas são mais simples / bonitas / inspiradoras / etc (por exemplo, provas do Livro).
Se você aceita a correspondência de Curry-Howard, a pergunta é principalmente filosófica. "As provas e os programas são diferentes? Claro. Como? Bem, chamamos provas de 'provas' e os programas 'programas'".
Ou, para ser menos irreverente, se houver um isomorfismo entre provas e programas - o que parece claramente existir -, sua pergunta será perguntada se existe algum oráculo capaz de distinguir os dois. Os seres humanos os categorizam como sendo diferentes (na maior parte), por isso é certamente discutível que tal oráculo exista. A questão importante passa a ser se existe alguma diferença significativa entre eles, o que está em discussão filosófica. O que é uma "prova"? Não há definição formal do que constitui uma prova; é um termo de arte, muito parecido com a noção de "efetivamente calculável" na tese de Church-Turing. Para esse assunto, "programa" também não tem definição formal.
Estas são palavras da linguagem natural usadas para categorizar diferentes campos da investigação matemática. O que Curry e Howard observaram é que esses dois campos diferentes estudavam a mesma coisa. Perceber essa conexão é importante porque diz que esses diferentes pesquisadores devem estar conversando entre si. Mas, em outro nível, perceber a conexão é desmentir a diferença entre eles. Ao lidar com um problema, às vezes é mais benéfico pensar nele como um problema de programação, enquanto outras vezes é mais benéfico pensar nele como um problema lógico. Essa diferença de perspectiva é, penso eu, a diferença importante entre eles. Mas se uma diferença de perspectiva constitui uma diferença de identidade é uma questão filosófica profunda que foi explorada pelo menos desde a época de Frege.Ueber Sinn und Bedeutung .