Strutture di dati in linguaggio di programmazione con tipi lineari

Supponiamo di avere a che fare con un linguaggio di programmazione che supporti i tipi lineari (i termini del tipo lineare possono essere usati al massimo una volta, per così dire). Ciò consente di trattare alcuni effetti computazionali (come la mutazione, anche cambiando il tipo di operando) in modo problematico per le lingue, i cui sistemi di tipi operano solo su "verità eterne".

Molte strutture di dati possono essere caratterizzate con tipi induttivi (elenchi e alberi sono esempi canonici). Se aggiungiamo tipi induttivi lineari al mix, possiamo anche gestire strutture di dati mutabili.

Tuttavia, non mi è chiaro come rappresentare strutture di dati che mostrano condivisione e riferimenti ciclici in un linguaggio di programmazione con tipi lineari (esempi di tali strutture di dati sono DAG e altri grafici, rappresentati da elenchi di adiacenza o qualcos'altro, elenchi ciclici). Possiamo farlo? Se ciò non è possibile, in che modo dovremmo estendere la lingua in modo da accogliere tali strutture di dati?

L'esempio più coinvolto che ho trovato finora è un elenco doppiamente collegato. Ci sono altri esempi?

pl.programming-languages type-theory linear-logic

— Bjørn Kjos-Hanssen
fonte

La linearità non è un vincolo sufficiente per definire una rappresentazione stateful unica, quindi la risposta alla tua domanda dipende da come interpreti la logica lineare in termini di stato. Questo si rifletterà in genere nel modo in cui devi interpretare $!A$ modalità.

Se la semantica di riferimenti prevista indica che tutti i puntatori sono valori univoci (ovvero esiste al massimo un singolo riferimento a un oggetto), le strutture dei grafici e dei punti non sono espressibili, per il tipo di motivo tautologico che un dag può contenere più riferimenti a lo stesso oggetto. In questo caso deve essere un calcolo che crea un nuovo valore di tipo , dal momento che si desidera Maps E . $!A$ $A$ $\delta_A : !A \multimap !A \otimes !A$ $\epsilon_A : !A \multimap A$

Tuttavia, supponiamo che tu voglia per rappresentare la condivisione . Quindi, gli oggetti possono essere con il conteggio dei riferimenti, con le mappe e possono essere realizzate come operazioni che contano solo i riferimenti. In questo caso, non è possibile utilizzare la linearità per assumere che sia sempre sicuro mutare valori, poiché esiste la condivisione. Ma puoi assicurarti che tutta l'allocazione di memoria sia esplicita nel tuo programma e che non ci siano cicli nell'heap. $!A$ $\delta_A : !A \multimap !A \otimes !A$ $\epsilon_A : !A \multimap A$

Le implementazioni più pratiche di tipi lineari non usano nessuna di queste due interpretazioni. Invece, i riferimenti sono visti come entità liberamente duplicabili e ciò che tracciamo linearmente sono in realtà capacità . Le capacità non sono valori di runtime; sono entità puramente concettuali che intendono rappresentare l'autorizzazione ad accedere a un riferimento. L'idea è che si programma in uno stile di passaggio delle autorizzazioni, e quindi anche se ci sono molti riferimenti allo stesso oggetto, una lettura o modifica di un pezzo di stato può avvenire solo se si ha anche la possibilità di accedervi. E poiché la capacità è lineare, sai che solo tu puoi cambiarla.

\begin{matrix} n e w & : & \forall α . α ⊸ \exists c : ι . c a p (c) \otimes r e f (α, c) \\ g e t & : & \forall α, c : ι . c a p (c) \otimes r e f (α, c) ⊸ α \otimes c a p (c) \otimes r e f (α, c) \\ s e t & : & \forall α, c : ι . c a p (c) \otimes r e f (α, c) \otimes α ⊸ c a 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) }$

Nell'API di cui sopra, va su , alcuni domini di indici in fase di compilazione e su tipi. Abbiamo un tipo che è una capacità indicizzata da , e un tipo , che è un tipo di riferimenti a accede una capacità . Chiamare e su un riferimento richiede la capacità , e chiamare crea un nuovo riferimento e una nuova capacità che condivide un indice comune. Tuttavia, $c$ $\iota$ $\alpha$ $\mathsf{cap}(c)$ $c$ $\mathsf{ref}(\alpha, c)$ $\alpha$ $c$ $\mathsf{get}$ $\mathsf{set}$ $c$ $\mathsf{new}$ $\mathsf{copy}$ -ing un riferimento non richiede l'accesso a nessuna funzionalità, quindi chiunque può copiare un riferimento purché non guardi al suo interno.

— Neel Krishnaswami
fonte

Grazie per una risposta stimolante. Sono interessato però, esiste una distinzione (tecnica) tra aliasing e condivisione? Esistono sistemi che possono gradualmente passare da lineari (al massimo un riferimento) a condivisi da al massimo n riferimenti a condivisi in modo illimitato?

1. Alias e condivisione sono sinonimi. 2. Sì, le interpretazioni in stile capacità, aumentate con le autorizzazioni frazionarie di Boyland lo consentono. Vedi anche il recente lavoro di Pottier sui calcoli delle capacità per la teoria e il lavoro di Aldrich e Bierhof su Plural per l'implementazione.

— Neel Krishnaswami,