Quali sono i problemi pratici con i tipi di intersezione e unione?

Sto progettando un semplice linguaggio di programmazione funzionale tipicamente statico come esperienza di apprendimento.

Sembra che il sistema di tipi che ho implementato finora potrebbe (con un po 'di lavoro extra) incorporare tipi di intersezione e unione, ad esempio potresti avere:

• <Union String Integer>
• <Union Integer Foo>
• L'intersezione dei due tipi sopra sarebbe semplice Integer
• L'unione dei due tipi sarebbe <Union String Integer Foo>

Il fatto che ciò sia possibile, ovviamente, non significa necessariamente che sia una buona idea progettuale. In particolare, sono un po 'preoccupato per le difficoltà di implementazione di mantenere i tipi disgiunti e / o gestire le sovrapposizioni.

Quali sono i pro / contro di incorporare tali funzionalità nel sistema di tipi?

Ecco alcune cose da tenere a mente:

• Anche se in genere pensiamo di sapere cosa si intende per insiemistica intersezione e l'unione, ci sono stati diversi diversa assume cosa esattamente intersezione e sindacali tipi sono . Quindi, vale la pena appuntarlo prima di iniziare un'implementazione.
• Un elemento che ritengo estremamente importante per comprendere le intersezioni e i sindacati è il concetto di raffinamento del tipo , essenzialmente l'idea che un programma abbia un certo "archetipo" intrinseco (ad esempio, " foo è una funzione da interi a interi"), che può quindi essere raffinato per esprimere proprietà più precise (ad esempio, " foo accetta numeri interi pari e interi dispari e numeri dispari"). Con il concetto di raffinamento in mano, la proprietà chiave che distingue le intersezioni e i sindacati dai prodotti e dalle somme è che l'intersezione / unione di due tipi può essere formata solo se perfezionano lo stesso archetipo. In altre parole, le regole di formazione del tipo per incroci e unioni possono essere espresse in questo modo (leggi "$S \sqsubset A$$S$$A$ $$\frac{S\sqsubset A \quad T \sqsubset A}{S\cap T\sqsubset A}\qquad \frac{S\sqsubset A \quad T \sqsubset A}{S\cup T\sqsubset A}$$ $$\frac{S\sqsubset A \quad T \sqsubset B}{S* T\sqsubset A*B}\qquad \frac{S\sqsubset A \quad T \sqsubset B}{S+T\sqsubset A+B}$$
• Poiché è possibile utilizzare intersezioni e sindacati per fare affermazioni più precise sul comportamento in fase di esecuzione di un programma, è naturale che la digitazione diventi sensibile all'ordine di valutazione. Ad esempio, i documenti (2) e (4) di seguito spiegano perché le regole "ovvie" (e abbastanza standard) di tipizzazione e sottotipo per intersezioni e sindacati sono in realtà non corrette per i linguaggi simili a ML (a causa della presenza di effetti collaterali e non terminazione). Sei stato avvertito!
• Per ragioni simili, l'inferenza di tipo globale diventa generalmente poco pratica o indecidibile. In effetti, l'intero concetto di "tipo principale" è probabilmente un'aringa rossa, dal momento che una funzione può soddisfare molte proprietà diverse che sono irrilevanti per l'uso previsto (ad esempio, " foo prende numeri primi interi in numeri superiori a 7"). Invece, gli approcci pratici alle intersezioni e ai sindacati (vedi (3) , (4) ) sono generalmente basati su una combinazione di inferenza e controllo.

Suppongo che alcuni dei punti di cui sopra possano sembrare negativi, anche se non li definirei "svantaggi" ma semplicemente "realtà" di tipi di intersezione e unione. D'altra parte, dal punto di vista della progettazione linguistica, uno dei motivi per fare lo sforzo di supportare incroci e sindacati (e per farli giusti!) È che consentono alle proprietà più precise dei programmi di essere espresse in modo abbastanza incrementale, richiedendo un trasformazione molto meno drastica della teoria dei tipi dipendenti.

Una breve lista di lettura:

1. Progettazione del linguaggio di programmazione Forsythe di John C. Reynolds
2. Tipi di intersezione ed effetti computazionali di Rowan Davies e Frank Pfenning
3. Verifica pratica del tipo di perfezionamento di Rowan Davies (tesi di laurea)
4. Controllo ortografico tridirezionale di Joshua Dunfield e Frank Pfenning