💻 computer science

Compositional Program Verification with Polynomial Functors in Dependent Type Theory

Questo articolo presenta un framework per la verifica composizionale dei programmi basato su funtori polinomiali nella teoria dei tipi dipendenti, formalizzato in Agda, che utilizza diagrammi di cablaggio per la composizione di implementazioni e specifiche e identifica la struttura categoriale sottostante per generalizzare l'approccio a contesti come la concorrenza e la verifica relazionale.

Autori originali: C. B. Aberlé

Pubblicato 2026-04-03

📖 5 min di lettura🧠 Approfondimento

CC BY 4.0

Autori originali: C. B. Aberlé

Articolo originale sotto licenza CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Questa è una spiegazione generata dall'IA dell'articolo qui sotto. Non è stata scritta né approvata dagli autori. Per precisione tecnica, consulta l'articolo originale. Leggi il disclaimer completo

Immagina di dover costruire un grattacielo. Se provassi a verificare che l'intero edificio sia sicuro guardandolo come un unico blocco gigante, saresti perso. È troppo complesso. La soluzione intelligente è: costruisci e verifica ogni singolo mattone, ogni trave e ogni finestra separatamente, assicurandoti che siano perfetti. Poi, quando li assembli, sai che l'intero edificio sarà solido perché lo sono le sue parti.

Questo è esattamente il cuore del paper di C.B. Aberlé, intitolato "Compositional Program Verification with Polynomial Functors in Dependent Type Theory".

Ecco una spiegazione semplice, usando metafore quotidiane, di come funziona questo sistema magico per verificare i software.

1. I "Polinomi" sono come le prese elettriche (Interfacce)

Nel mondo dei computer, ogni programma ha bisogno di "parlare" con altri programmi. Immagina che ogni programma sia una scatola nera.

L'Interfaccia (Polinomio): È come il pannello frontale della scatola. Ci dice: "Ho bisogno di una presa di corrente (input) e ti darò una luce (output)".
Nel linguaggio del paper, queste scatole sono chiamate funzioni polinomiali. Sembrano complicati, ma sono solo un modo matematico per dire: "Se mi dai questo tipo di dato, io ti restituisco quel tipo di dato".

2. I "Moduli" sono come i blocchi Lego (Implementazioni)

Ora, immagina di voler costruire un castello di Lego.

Hai un modulo "Fondamenta" che ha bisogno di "Terra" e ti dà "Stabilità".
Hai un modulo "Muro" che ha bisogno di "Stabilità" e ti dà "Altezza".
Il paper dice: invece di scrivere tutto il codice del castello in una volta sola, scrivi il codice per le fondamenta e per il muro separatamente.
La Magia: Puoi collegare le fondamenta al muro. Se le fondamenta funzionano e il muro funziona, il muro sopra le fondamenta funziona automaticamente. Questo è il composizione. Non devi ridisegnare tutto ogni volta; basta collegare i pezzi.

3. Le "Specifiche" sono come i contratti legali (Verifica)

Fino a qui, abbiamo detto che i pezzi si incastrano. Ma come sappiamo che il muro non crollerà?

Qui entra in gioco la Verifica. Immagina che ogni modulo abbia un contratto legale scritto in un linguaggio preciso (la tipologia dipendente).
Il contratto dice: "Se mi dai un mattone che pesa meno di 10kg (precondizione), io ti garantisco che il muro reggerà fino a 10 piani (postcondizione)".
Il paper introduce un modo per scrivere questi contratti in modo che, quando colleghi due moduli, i loro contratti si "fondono" automaticamente. Se il contratto delle fondamenta dice "regge 100kg" e il contratto del muro dice "ne richiede 50", il sistema sa matematicamente che l'unione è sicura.

4. Le "Macchine di Mealy" sono come gli operai che eseguono il lavoro (Semantica Operativa)

Avere i pezzi e i contratti è bello, ma come facciamo a farli funzionare davvero?

Immagina le Macchine di Mealy come degli operai robot.
Quando dai un input a un'interfaccia (es. "Premi il tasto"), l'operario robot esegue l'azione, cambia il suo stato interno (es. "Ora ho premuto il tasto") e ti dà l'output.
Il paper mostra che puoi prendere un operario che sa fare il lavoro delle fondamenta e uno che sa fare il lavoro del muro, e unirli in un unico grande operario che costruisce l'intero castello, mantenendo traccia di tutto ciò che fa.

5. I "Diagrammi di Cablaggio" sono come la mappa dei cavi (Composizione)

Come uniamo tutto questo? Usiamo i Diagrammi di Cablaggio.

Immagina una scatola di strumenti dove hai dei cavi che escono da una parte e entrano dall'altra.
Il paper dice: puoi disegnare una mappa (un diagramma) che mostra come collegare le uscite di un modulo alle entrate di un altro.
La cosa incredibile è che se ogni singolo modulo sulla mappa è verificato e sicuro, allora l'intero disegno è verificato e sicuro. Non devi controllare i cavi uno per uno; la struttura stessa garantisce la sicurezza.

6. Il "Segreto" Matematico (Categorie e Funzioni)

Perché tutto questo funziona? Il paper rivela che c'è una struttura matematica nascosta (la teoria delle categorie) che agisce come l'impalcatura invisibile.

Immagina che le interfacce, i contratti e gli operai siano tutti pezzi di un unico grande puzzle.
Gli autori hanno scoperto che questo puzzle ha una forma precisa (un "functore monoidale") che assicura che, non importa quanto complesso diventi il sistema, le regole di sicurezza non si rompano mai quando si uniscono i pezzi.

In sintesi: Perché è importante?

Oggi i software sono enormi, oscuri e pieni di bug. Spesso proviamo a correggere gli errori alla fine, quando è troppo tardi.
Questo paper ci dice: "Non preoccuparti dell'intero sistema. Costruisci piccoli pezzi, verifica che ogni pezzo rispetti il suo contratto, e poi uniscili."

È come se avessimo un modo per dire a un architetto: "Non devi controllare se l'intero grattacielo crollerà. Controlla solo che ogni mattone sia perfetto e che il cemento tenga. Se lo fai, l'edificio sarà sicuro per sempre."

Questo approccio rende la creazione di software sicuri, complessi e affidabili (come quelli per le banche, i voli spaziali o l'intelligenza artificiale) molto più gestibile e meno soggetta a errori umani.

1. Il Problema

I sistemi software moderni sono spesso complessi e "opachi", rendendo difficile verificarne il comportamento corretto. L'approccio tradizionale alla verifica spesso richiede l'analisi monolitica dell'intero sistema, il che diventa intrattabile all'aumentare della scala.
Il problema centrale affrontato è come decomporre la verifica di programmi complessi in componenti più semplici, verificare questi componenti in modo indipendente e poi comporre i risultati in una verifica globale valida. Esiste la necessità di un framework unificato che gestisca simultaneamente:

Le interfacce dei programmi.
Le implementazioni (moduli).
Le specifiche (pre/post-condizioni).
La semantica operativa.
La composizione di tutti questi elementi tramite strutture di dipendenza (diagrammi di cablaggio).

2. Metodologia

L'autore propone un framework basato su functori polinomiali all'interno della teoria dei tipi dipendenti (formalizzato in Agda). La metodologia si articola nei seguenti pilastri concettuali:

Functori Polinomiali come Interfacce: Un funtore polinomiale $P(y) = \sum_{a:A} y^{B(a)}$ rappresenta l'interfaccia di una funzione dipendente $(a:A) \to B(a)$ . Qui, $A$ è il tipo delle "posizioni" (input) e $B(a)$ è il tipo delle "direzioni" (output).
Morfismi di Kleisli come Implementazioni: Un modulo che implementa un'interfaccia $p$ chiamando un'altra interfaccia $q$ è modellato come un morfismo $p \Rightarrow \text{Free}_q$ , dove $\text{Free}_q$ è il monade libero su $q$ . Questo cattura la sequenzialità e la possibilità di chiamate ricorsive o multiple.
Polinomi Dipendenti come Specifiche: Per la verifica, si introducono i "polinomi dipendenti" (DepPoly). Questi estendono i functori polinomiali aggiungendo:
- Precondizioni $C(a)$ sugli input.
- Postcondizioni $D(a, c, b)$ sugli output, dipendenti dall'input e dalla prova della precondizione.
  Questo equivale a una generalizzazione dei triplette di Hoare nel contesto dei functori polinomiali.
Macchine di Mealy come Semantica Operativa: Per dare un significato esecutivo ai moduli, si utilizzano le macchine di Mealy (automati a stati finiti con output dipendenti dallo stato). Una macchina di Mealy per un'interfaccia $p$ è una co-algebra che, dato un input, produce un output e un nuovo stato.
Composizione tramite Diagrammi di Cablaggio (Wiring Diagrams): La composizione di moduli non è limitata a una semplice concatenazione lineare. Il framework utilizza diagrammi di cablaggio per descrivere strutture di dipendenza arbitrarie, permettendo di collegare le uscite di alcuni moduli agli ingressi di altri in modo modulare.

3. Contributi Chiave

Framework di Verifica Compositiva:
L'autore dimostra che le implementazioni e le loro verifiche si compongono lungo i diagrammi di cablaggio. Se un modulo $f$ è verificato rispetto a una specifica $r$ assumendo che le sue dipendenze soddisfino $s$ , e le dipendenze sono a loro volta verificate, allora il modulo composto eredita una verifica corretta. Questo è formalizzato attraverso il monade libero dipendente ( $\text{FreeDep}$ ).
Semantica Operativa Verificata:
Viene introdotta la nozione di Macchina di Mealy Dipendente ( $\text{DepMealy}$ ). Questa struttura non solo esegue il programma (tramite la macchina di Mealy sottostante), ma trasporta anche le prove delle specifiche (invarianti) attraverso l'esecuzione. Viene dimostrato che la composizione di un programma verificato con una macchina di Mealy verificata produce una nuova macchina di Mealy verificata.
Struttura Categorical Astratta:
Il lavoro identifica la struttura matematica sottostante come un funtore monoidale dalla categoria delle specifiche alla categoria delle interfacce, accompagnato da una trasformazione naturale monoidale tra presheaf monoidali lassi.
- Categoria delle Interfacce ($Int$): Oggetti sono polinomi, morfismi sono implementazioni (Kleisli).
- Categoria delle Specifiche ($Spec$): Oggetti sono coppie (polinomio, polinomio dipendente).
- Presheaf: Le macchine di Mealy formano un presheaf lasso monoidale su $Int$, e le macchine di Mealy verificate formano un presheaf lasso monoidale su $Spec$.
  Questa astrazione permette di generalizzare il framework ad altri contesti (es. concorrenza).
Estensione alla Concorrenza (Appendice A):
Il framework viene esteso per gestire moduli concorrenti introducendo una somma parallela ( $\|$ ) invece della somma coprodotto ( $\oplus$ ). Questo permette di chiamare più dipendenze simultaneamente e di verificare proprietà relazionali (es. non-interferenza, monotonia) che non possono essere espresse come pre/post-condizioni unarie.
Formalizzazione Completa:
L'intero sviluppo teorico, inclusi gli esempi (Fold, Append, Fibonacci) e le dimostrazioni, è stato formalizzato nel linguaggio di programmazione e dimostrazione Agda.

4. Risultati ed Esempi

Esempio Fold/Append/Concat: Viene mostrato come implementare operazioni ricorsive su liste (come append e concat) componendo moduli più piccoli (Base e Step). La verifica di append viene costruita componendo le verifiche dei casi base e ricorsivi, utilizzando induzione strutturale all'interno del framework dei polinomi dipendenti.
Fibonacci con Stato: Viene implementata una macchina di Mealy per la sequenza di Fibonacci utilizzando un effetto di stato. Viene verificato che la macchina mantenga un'invariante di stato corretta (la coppia di numeri nello stato corrisponde sempre a due numeri consecutivi di Fibonacci) e che l'output sia corretto.
Composizione Corretta: Viene provato che la composizione di implementazioni verificate preserva le proprietà di verifica, permettendo di ragionare localmente sui moduli senza dover riesaminare l'intero sistema.

5. Significato e Impatto

Questo lavoro è significativo per diversi motivi:

Unificazione: Offre una visione unificata che collega teoria delle categorie (functori polinomiali, monadi, comonadi), teoria dei tipi dipendenti e semantica operativa.
Scalabilità della Verifica: Abilita la verifica di sistemi complessi attraverso il ragionamento modulare e compositivo, riducendo il carico cognitivo e computazionale rispetto alla verifica monolitica.
Generalità: La struttura astratta identificata (funtori monoidali e trasformazioni naturali) suggerisce che il metodo è applicabile oltre i moduli sequenziali, estendendosi naturalmente alla concorrenza e alla verifica relazionale.
Fondamento per l'Automazione: La natura compositiva del framework lo rende un candidato ideale per l'automazione tramite tattiche o procedure di elaborazione in assistenti di prova, facilitando l'adozione della verifica formale in grandi sistemi software.
Sicurezza e Flusso di Informazioni: La capacità di rendere esplicito il flusso di informazioni tramite diagrammi di cablaggio apre nuove possibilità per la verifica di proprietà di sicurezza e politiche di flusso di informazioni in sistemi costruiti su componenti opachi (API, modelli ML).

In sintesi, il paper stabilisce un nuovo paradigma per la verifica dei programmi, trasformando la verifica da un processo monolitico a uno modulare, composizionale e formalmente fondato sulla teoria delle categorie e sui tipi dipendenti.