Relação entre a teoria dos tipos Russelliana e os sistemas de tipos


12

Recentemente, percebi que existe algum tipo de relação entre a teoria de tipos russelliana e os sistemas de tipos, como encontrado, por exemplo, em Haskell. Na verdade, algumas das notações para tipos em Haskell parecem ter precursores na teoria dos tipos. Mas, IMHO, a motivação de Russell em 1908 foi evitar o paradoxo de Russell, e não tenho certeza de como isso está relacionado aos sistemas de tipos na ciência da computação.

O paradoxo de Russell, de uma forma ou de outra, é algo com o qual teríamos que nos preocupar, por exemplo, se não tivéssemos um bom sistema de tipos em um determinado idioma?

Respostas:


8

`` Teoria dos tipos ", no sentido de linguagens de programação e Russell, está intimamente relacionada. De fato, o campo moderno da teoria dos tipos dependentes visa fornecer fundamentos construtivos para a matemática. Diferentemente da teoria dos conjuntos, a maioria das pesquisas em teoria dos tipos baseia-se a matemática é feita em assistentes de provas como Coq, NuPRL ou Agda. Como tal, as provas feitas nesses sistemas não são apenas "formalizáveis", mas na verdade totalmente formais e verificadas mecanicamente. Usando táticas e outras técnicas de automação de provas, tentamos provar isso. sistemas "de alto nível" e, portanto, se assemelham à matemática informal, mas como tudo é verificado, temos garantias muito melhores de correção.

Veja aqui

Os tipos em linguagens de programação comuns tendem a ser mais limitados, mas a meta-teoria é a mesma.

Algo semelhante ao paradoxo de Russell é uma questão importante na teoria dos tipos dependentes. Em particular, ter

Type : Type

geralmente leva à contradição. Coq e trabalho similar aninhando universos

Type_0 : Type_1

mas em Coq, por padrão, esses números estão implícitos, pois normalmente não importam para o programador.

Em alguns sistemas (Agda, Idris), a regra de digitação é ativada por meio de um sinalizador de compilação. Isso torna a lógica inconsistente, mas geralmente facilita a programação / prova exploratória.

Mesmo em idiomas mais tradicionais, o paradoxo de Russell aparece ocasionalmente. Por exemplo, em Haskell, é possível uma codificação do paradoxo de Russell combinando impredicatividade e maiúsculas e minúsculas, permitindo que se construa termos divergentes sem recursão, mesmo no nível de tipo. Haskell é `` inconsistente '' (quando interpretado como uma lógica da maneira usual), pois suporta recursão de tipo e nível de valor, sem mencionar exceções. No entanto, esse resultado é bastante interessante.


Obrigado pela sua resposta detalhada - no que diz respeito à prova, ainda não existem ferramentas à vista para provar a correção de programas em linguagens imperativas como C ++ ou Java, certo? Eu adoraria colocar minhas mãos em uma dessas ... Percebo que essa é uma tangente completa. Eu sei sobre Coq e Agda, mas elas não parecem ser as ferramentas certas para provar a correção de programas escritos em C ++ ou Java.
24513 Frank

3
existem algumas ferramentas. Alguns para C, muitos para Java e toneladas para Ada. Veja, por exemplo: Por que (Java, C, Ada), Krakatoa (Java) ou SPARK (subconjunto Ada com ferramentas muito boas). Para C ++, porém, nem tanto. Você também pode estar interessado em YNot (Coq DSL).
Philip JF

3

Você está certo sobre a motivação de Russell. Seu paradoxo atormenta todas as teorias de conjuntos que admitem axiomas irrestritos de compreensão no sentido de que: qualquer função proposicional determina um conjunto, ou seja, o de todas as entidades que satisfazem a função. Entre as teorias ou baseadas em conjuntos que tinham essa falha estavam a ingênua teoria dos conjuntos de Cantor e o sistema de Grundgesetze de Frege (especificamente: axioma 5).

Como os tipos são considerados tipos especiais de conjuntos, se não for tomado cuidado, um paradoxo semelhante pode se infiltrar em um sistema de tipos. Dito isto, não conheço nenhum sistema de tipos que tenha sofrido esse destino. Só me lembro das primeiras tentativas de Church de formular o cálculo lambda nos anos 30, que se mostraram inconsistentes (Kleene-Rosser Paradox), mas essa não era devida a tipos nem estava relacionada ao paradoxo de Russell.

Atualização : Veja a resposta de Philip para obter uma resposta real à sua pergunta.


1
Obrigado pela sua resposta. Provavelmente, existem alternativas ao types-a-la-Russell para evitar o paradoxo de Russell. Alguma dessas soluções alternativas teria algo interessante para contribuir com as linguagens de computador? Os tipos mundanos são muito úteis para especificar claramente contratos entre partes do código e, mesmo antes disso, para fornecer semântica a todos os programas. Haveria outra semântica que poderia ser obtida com algo mais que tipos? (Eu não tenho idéia o que isso seria :-)
Frank

1
Sim, muitas alternativas (Quine's NF, ZFC, etc), mas não vejo nenhuma conexão direta entre a crise fundamental e as linguagens de programação. Se você considerar a teoria dos tipos de Martin Lof como uma linguagem de programação, pode haver alguma conexão voltando ao intuicionismo. No que diz respeito à semântica das linguagens de programação, existem algumas linguagens básicas, como PDL (Propositional Dynamic Logic), que possuem semântica Kripke (ou mundos possíveis). Mas tipos parecem-me tão fundamental que eles só poderão estar por trás das cenas :)
Hunan Rostomyan

1
Mas os tipos são meio chatos: você quer e precisa deles, mas gostaria de não precisar especificá-los (por isso, IMHO, por que temos sistemas de inferência de tipos em idiomas como Haskell ou Ocaml (eu amo esses idiomas)). No outro extremo do espectro, o Python parece muito intuitivo e é agradável (e eficiente em termos de tempo de codificação) não ter que se preocupar muito com os tipos nessa linguagem. Talvez a inferência de tipo seja a melhor do mundo - mas esse é o engenheiro falando. Eu estava apenas sonhando que a matemática poderia contribuir outro conceito significativo (como tipos) para ciência da computação :-)
Frank

1
@Frank Toda vez que uso um idioma sem tipos estáticos (principalmente Ruby), odeio a experiência, porque odeio erros de execução evitáveis. Então, isso parece ser uma questão de gosto principalmente. Concordo que a inferência de tipo poderosa pode oferecer o melhor dos dois mundos. É provavelmente por isso que gosto tanto de Scala.
Raphael

Não estou convencido de que não ter tipos "automaticamente" leve a erros de tempo de execução, como você parece sugerir :-) Eu nunca tive um problema no Python.
15243 Frank

3

Como você menciona o Python, a pergunta não é puramente teórica do tipo. Então, tento dar uma perspectiva mais ampla sobre os tipos. Tipos são coisas diferentes para pessoas diferentes. Reuni pelo menos 5 noções distintas (mas relacionadas) de tipos:

  1. Sistemas de tipos são sistemas lógicos e teorias de conjuntos.

  2. Um sistema de tipos associa um tipo a cada valor calculado. Examinando o fluxo desses valores, um sistema de tipos tenta provar ou garantir que nenhum erro de tipo possa ocorrer.

  3. Type é uma classificação que identifica um dos vários tipos de dados, como valor real, número inteiro ou booleano, que determina os valores possíveis para esse tipo; as operações que podem ser feitas com valores desse tipo; o significado dos dados; e a maneira como os valores desse tipo podem ser armazenados

  4. Tipos de dados abstratos permitem abstração de dados em idiomas de alto nível. Os ADTs geralmente são implementados como módulos: a interface do módulo declara procedimentos que correspondem às operações do ADT. Essa estratégia de ocultação de informações permite que a implementação do módulo seja alterada sem atrapalhar os programas clientes.

  5. As implementações da linguagem de programação usam tipos de valores para escolher o armazenamento que os valores precisam e os algoritmos para operações nos valores.

As citações são da Wikipedia, mas posso fornecer melhores referências, se necessário.

Os tipos 1 surgiram do trabalho de Russel, mas hoje eles não estão apenas protegidos de paradoxos: a linguagem tipificada da teoria dos tipos de homotopia é uma nova maneira de codificar a matemática em uma linguagem formal e compreensível por máquina, e uma nova maneira para os humanos entenderem os fundamentos de matemática. (A maneira "antiga" é codificar usando uma teoria axiomática dos conjuntos).

Os tipos 2-5 surgiram na programação de várias necessidades diferentes: para evitar erros, para classificar os designers e programadores de software de dados, projetar sistemas grandes e implementar linguagens de programação eficientemente, respectivamente.

Os sistemas de tipos em C / C ++, Ada, Java, Python não surgiram do trabalho de Russel ou do desejo de evitar bugs. Surgiram da necessidade de descrever diferentes tipos de dados existentes (por exemplo, "sobrenome é uma cadeia de caracteres e não um número"), modularizar o design do software e escolher representações de baixo nível para os dados da melhor maneira possível. Esses idiomas não têm tipos 1 ou 2. O Java garante segurança relativa contra bugs, não por meio da comprovação da correção do programa usando o sistema de tipos, mas por um design cuidadoso da linguagem (sem aritmética de ponteiro) e do sistema de tempo de execução (máquina virtual, verificação de bytecode). O sistema de tipos em Java não é um sistema lógico nem uma teoria de conjuntos.

No entanto, o sistema de tipos na linguagem de programação Agda é uma variante moderna do sistema de tipos de Russel (com base em trabalhos posteriores ou Per Martin-Lof e outros matemáticos). O sistema de tipos no Agda é projetado para expressar propriedades matemáticas do programa e provas dessas propriedades, é um sistema lógico e uma teoria de conjuntos.

Não há distinção em preto e branco aqui: muitos idiomas se encaixam no meio. Por exemplo, o sistema de tipos da linguagem Haskell tem raízes no trabalho de Russel, pode ser visto como um sistema simplificado da Agda, mas, do ponto de vista matemático, é inconsistente (auto-contraditório) se visto como um sistema lógico ou uma teoria de conjuntos.

No entanto, como um veículo teórico para proteger os programas Haskell de bugs, ele funciona muito bem. Você ainda pode usar tipos para codificar certas propriedades e suas provas, mas nem todas as propriedades podem ser codificadas, e o programador ainda pode violar as propriedades comprovadas se ele usar hacks sujos desencorajados.

O sistema de tipos de Scala está ainda mais longe do trabalho de Russel e da linguagem de prova perfeita da Agda, mas ainda tem raízes no trabalho de Russel.

Quanto à prova de propriedades de linguagens industriais cujos sistemas de tipos não foram projetados para isso, existem muitas abordagens e sistemas.

Para abordagens interessantes, mas diferentes, consulte o projeto de pesquisa Coq e Microsoft Boogie. A Coq conta com a teoria dos tipos para gerar programas imperativos a partir dos programas da Coq. Boogie baseia-se na anotação de programas imperativos com propriedades e na comprovação dessas propriedades com o provador do teorema Z3, usando uma abordagem completamente diferente da Coq.

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.