Estruturas de dados em linguagem de programação com tipos lineares

Suponha que estamos lidando com uma linguagem de programação que suporta tipos lineares (os termos do tipo linear podem ser usados no máximo uma vez, por assim dizer). Isso permite tratar alguns efeitos computacionais (como mutação, até mesmo alterar o tipo do operando) de uma maneira problemática para as linguagens, cujos sistemas de tipos operam apenas em "verdades eternas".

Muitas estruturas de dados podem ser caracterizadas com tipos indutivos (listas e árvores são exemplos canônicos). Se adicionarmos tipos indutivos lineares à mistura, também podemos lidar com estruturas de dados mutáveis.

No entanto, não está claro para mim como representar estruturas de dados que exibem compartilhamento e referências cíclicas em uma linguagem de programação com tipos lineares (exemplos de tais estruturas de dados são DAGs e outros gráficos, representados por listas de adjacências ou outra coisa, listas cíclicas). Podemos fazer isso? Se não for possível, de que maneira devemos estender a linguagem para acomodar essas estruturas de dados?

O exemplo mais envolvido que encontrei até agora é uma lista duplamente vinculada. Existem outros exemplos?

pl.programming-languages type-theory linear-logic

— Bjørn Kjos-Hanssen
fonte

A linearidade não é uma restrição suficiente para definir uma representação com estado única e, portanto, a resposta à sua pergunta depende de como você interpreta a lógica linear em termos de estado. Isso normalmente será refletido em como você deve interpretar o modalidade. $!A$

Se a semântica pretendida das referências disser que todos os ponteiros são valores únicos (ou seja, existe no máximo uma única referência a um objeto), os dags e as estruturas gráficas não são expressáveis, pelo tipo de razão tautológica em que um dag pode conter várias referências a o mesmo objeto. Nesse caso deve ser um cálculo que cria um novo valor do tipo , desde que você quer mapas e $!A$ $A$ $\delta_A : !A \multimap !A \otimes !A$ $\epsilon_A : !A \multimap A$ .

No entanto, suponha que você queira para representar o compartilhamento . Então, os objectos podem ser com a contagem de referência recolhidos-lixo, com os mapas e pode ser realizado como operações que apenas contagens de referência. Nesse caso, você não pode usar a linearidade para assumir que é sempre seguro alterar valores, já que há compartilhamento. Mas você pode garantir que toda a alocação de memória seja explícita no seu programa e que não haja ciclos no heap. $!A$ $\delta_A : !A \multimap !A \otimes !A$ $\epsilon_A : !A \multimap A$

A maioria das implementações práticas de tipos lineares não usa nenhuma dessas duas interpretações. Em vez disso, as referências são vistas como entidades livremente duplicáveis, e o que rastreamos linearmente são de fato recursos . Recursos não são valores de tempo de execução; elas são entidades puramente conceituais, destinadas a representar a permissão para acessar uma referência. A idéia é que você programe em um estilo de passagem de permissão e, mesmo que haja muitas referências ao mesmo objeto, uma leitura ou modificação de um pedaço de estado só poderá ocorrer se você também tiver a capacidade de acessá-lo. E como a capacidade é linear, você sabe que somente você pode alterá-la.

\begin{matrix} n e w & : & \forall α . α ⊸ \exists c : ι . c a p (c) \otimes r e f (α, c) \\ g e t & : & \forall α, c : ι . c uma p (c) \otimes r e f (α, c) ⊸ α \otimes c uma p (c) \otimes r e f (α, c) \\ s e t & : & \forall α, c : ι . c uma p (c) \otimes r e f (α, c) \otimes α ⊸ c uma p (c) \otimes r e f (α, c) \\ c o p y & : & \forall α, c : ι . r e f (α, c) ⊸ r e f (α, c) \otimes r e f (α, c) \end{matrix}

$\array{ \mathsf{new} & : & \forall \alpha. \;\alpha \multimap \exists c : \iota. \mathsf{cap}(c) \otimes \mathsf{ref}(\alpha, c) \\ \mathsf{get} & : & \forall \alpha, c:\iota. \;\mathsf{cap}(c) \otimes \mathsf{ref}(\alpha, c) \multimap \alpha \otimes \mathsf{cap}(c) \otimes \mathsf{ref}(\alpha, c) \\ \mathsf{set} & : & \forall \alpha, c:\iota. \;\mathsf{cap}(c) \otimes \mathsf{ref}(\alpha, c) \otimes \alpha \multimap \mathsf{cap}(c) \otimes \mathsf{ref}(\alpha, c) \\ \mathsf{copy} & : & \forall \alpha, c:\iota.\; \mathsf{ref}(\alpha,c) \multimap \mathsf{ref}(\alpha,c) \otimes \mathsf{ref}(\alpha,c) }$

Na API esboçada acima, varia sobre , algum domínio de índices em tempo de compilação e varia sobre tipos. Temos um tipo que é uma capacidade indexada por , e um tipo , que é um tipo de referência a acessada por uma capacidade . Chamar e em uma referência requer a capacidade , e ligando $c$ $\iota$ $\alpha$ $\mathsf{cap}(c)$ $c$ $\mathsf{ref}(\alpha, c)$ $\alpha$ $c$ $\mathsf{get}$ $\mathsf{set}$ $c$ cria uma nova referência e um novo recurso que compartilha um índice comum. No entanto, ing uma referência não requer acesso a qualquer recurso, para que qualquer pessoa pode copiar uma referência, desde que eles não olhar para ele. $\mathsf{new}$ $\mathsf{copy}$

— Neel Krishnaswami
fonte

Obrigado por uma resposta instigante. Estou interessado, porém, existe uma distinção (técnica) entre alias e compartilhamento? Existem sistemas que podem gradualmente passar de linear (no máximo uma referência) para compartilhado por no máximo n referências para compartilhado de maneira irrestrita?

1. Alias e compartilhamento são sinônimos. 2. Sim, interpretações no estilo de capacidade, aumentadas com as permissões fracionárias de Boyland, permitem isso. Veja também o trabalho recente de Pottier sobre cálculo de capacidade para teoria e o trabalho de Aldrich e Bierhof sobre Plural para implementação.

— Neel Krishnaswami