Técnicas de prova para mostrar que a verificação de tipo dependente é decidível


10

Estou em uma situação em que preciso mostrar que a digitação é decidível para um cálculo de tipo dependente em que estou trabalhando. Até agora, pude provar que o sistema está fortemente normalizando e, portanto, que a igualdade de definição é decidível.

Em muitas referências que li, a decisão de digitar tipicamente é listada como um corolário de forte normalização, e acredito nisso nesses casos, mas estou me perguntando como alguém realmente mostra isso.

Em particular, estou preso ao seguinte:

  • Só porque os termos bem digitados estão fortemente normalizando, não significa que o algoritmo não retornará para sempre em entradas não bem digitadas
  • Como as relações lógicas geralmente são usadas para mostrar forte normalização, não há uma métrica decrescente conveniente à medida que avançamos na digitação de termos. Portanto, mesmo que minhas regras de tipo sejam direcionadas à sintaxe, não há garantia de que a aplicação das regras acabará.

Gostaria de saber, alguém tem uma boa referência a uma prova de decidibilidade de datilografia para uma linguagem tipicamente dependente? Se é um cálculo pequeno, tudo bem. Qualquer coisa que discuta técnicas de prova para mostrar decidibilidade seria ótimo.


7
Os algoritmos bidirecionais comuns de verificação de tipo nunca tentam normalizar um termo (ou um tipo) sem primeiro verificar se ele está bem digitado (ou bem formado). Você não precisa se preocupar com a normalização de termos não digitados.
Andrej Bauer

7
Em relação à aplicação das regras: todas as regras de termos e tipos diminuem a meta, exceto a conversão de tipos. Portanto, precisamos controlar a conversão de tipos, o que fazemos usando uma abordagem bidirecional.
Andrej Bauer

Respostas:


9

De fato, há uma sutileza aqui, embora as coisas funcionem bem no caso de verificação de tipo. Escreverei o problema aqui, pois parece surgir em muitos tópicos relacionados e tentarei explicar por que as coisas funcionam bem ao verificar tipos em uma teoria de tipos dependentes "padrão" (serei deliberadamente vago, pois esses problemas tendem a surgir independentemente):

DΓt:ADΓA:ssutBΔDΔu:B

Esse fato legal é um pouco difícil de provar e compensado por um contra-fato bastante desagradável:

Fato 2: Em geral, e não são sub-derivações de !DD D

Isso depende um pouco da formulação precisa do seu sistema de tipos, mas a maioria dos sistemas "operacionais" implementados na prática satisfazem o Fato 2.

Isso significa que você não pode "passar para sub-termos" ao raciocinar por indução em derivações ou concluir que a afirmação indutiva é verdadeira sobre o tipo de termo que você está tentando provar algo.

Esse fato o incomoda bastante ao tentar provar declarações aparentemente inocentes, por exemplo, que sistemas com conversão de tipos são equivalentes àqueles com conversão de tipos.

No entanto , no caso de inferência de tipo, você pode fornecer um algoritmo de inferência de tipo e classificação simultâneo (o tipo do tipo) por indução na estrutura do termo, o que pode envolver um algoritmo direcionado a tipo, como Andrej sugere. Para um determinado termo (e contexto , você falha ou encontra tal que e . Você não precisa usar a hipótese indutiva para encontrar o último derivação e, em particular, você evita o problema explicado acima.tΓA,sΓt:AΓA:s

O caso crucial (e o único caso que realmente requer conversão) é a aplicação:

infer(t u):
   type_t, sort_t <- infer(t)
   type_t' <- normalize(type_t)
   type_u, sort_u <- infer(u)
   type_u' <- normalize(type_u)
   if (type_t' = Pi(A, B) and type_u' = A' and alpha_equal(A, A') then
      return B, sort_t (or the appropriate sort)
   else fail

Todas as chamadas para normalizar foram feitas em termos bem digitados, pois esse é o invariante para infero sucesso.


A propósito, como é implementado, o Coq não possui verificação de tipo decidível, pois normaliza o corpo das fixinstruções antes de tentar digitá-las.

De qualquer forma, os limites das formas normais de termos bem digitados são tão astronômicos, que o teorema da decidibilidade é principalmente acadêmico neste momento. Na prática, você executa o algoritmo de verificação de tipo enquanto tiver paciência e tenta uma rota diferente se ainda não tiver terminado.


Achei sua resposta muito útil, obrigado. Eu tenho duas perguntas: 1. O que significa "sistemas operacionais"? Qual a alternativa? 2. Você pode ser mais explícito com o exemplo: o que significa (que fato estamos tentando provar?) "Sistemas com conversão de tipos são equivalentes aos sistemas com conversão de tipos". Obrigado!
Łukasz Lew 12/10

11
@ ToukaszLew A alternativa a um sistema operacional (implementado na prática, por exemplo, no software Coq ou Agda) seria um sistema teórico, útil para provar propriedades meta-teóricas, mas é ineficiente ou inconveniente para uso na prática. Provar a equivalência de um sistema operacional e um sistema teórico geralmente é uma parte importante de um projeto de sistema. Eu falo mais sobre isso aqui: cstheory.stackexchange.com/a/41457/3984
cody

Acho que vale a pena mencionar o mais simples e fácil de Lennart Augustsson ! . Esta é uma implementação mínima de Haskell da verificação de tipo e alguma inferência para o cálculo lambda de tipo dependente. Existe um código que corresponde intimamente ao de Cody infer(t u):; para encontrá-lo, procure por " tCheck r (App f a) =". Para uma implementação mais completa, mas ainda simples, você pode conferir o MortetypeWith .
Łukasz Lew 12/10

11
@ ŁukaszLew O problema de conversão digitada vs não tipada é uma questão aberta bem conhecida que relaciona 2 formulações de teorias de tipos e foi resolvida recentemente: pauillac.inria.fr/~herbelin/articles/…
cody

O que significa ? ut
jonaprieto
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.