Il pattern HKT leggero

Il meccanismo alla base della codifica ha un nome: defunzionalizzazione. Invece di usare una vera funzione di tipo di ordine superiore, rappresentiamo ogni funzione tramite un tag e la risolviamo con un'unica ricerca di primo ordine. Il registro URItoKind è proprio questa tabella di ricerca.

Kind<F, A> è l'interfaccia pubblica del modello. Lo si può leggere come "il costruttore F applicato a A". Nasconde l'indicizzazione del registro dietro un nome chiaro.

F deve essere un URI registrato. Lo si vincola con extends URIS, così è possibile usare solo tag validi e gli errori di battitura diventano errori di compilazione.

Ora è possibile scrivere la firma di Functor che prima era impossibile. Sostituendo ogni F<A> con Kind<F, A>, il compilatore la accetta.

Quando si fissa F a un URI concreto, Kind viene risolto nel tipo reale del contenitore. Un Functor<"Array"> ha un map da A[] a B[].

Alcuni costruttori accettano due argomenti, come Either<E, A>. fp-ts estende il modello con URItoKind2 e Kind2<F, E, A> per il kind * -> * -> *. L'idea si estende aggiungendo altri registri.

fp-ts ha stabilito la convenzione seguita in tutto questo corso: una stringa URI per ogni tipo di dato, un registro URItoKind esteso tramite la fusione delle dichiarazioni e Kind per la risoluzione. Riconoscerla permette di leggere le firme di tipo di fp-ts ed Effect.

Un'"istanza" di un'astrazione è un valore che la implementa per uno specifico URI. L'istanza contiene il map concreto. Nella prossima lezione scriveremo l'istanza di Array; qui ne vediamo la struttura.

Si parla di modello HKT leggero perché non richiede modifiche al compilatore né una sintassi speciale, ma solo interfacce e accessi indicizzati. Il costo è un po' di verbosità (URI e registri), in cambio di un codice realmente generico rispetto ai contenitori.

Il modello è verboso e i messaggi di errore possono essere criptici, perché fanno riferimento alla codifica invece che al dominio dell'applicazione. Inoltre, ogni contenitore deve essere registrato. Nella maggior parte delle applicazioni si usano librerie che lo fanno già, invece di costruirlo autonomamente.

Lo schema completo dell'HKT leggero è il seguente: definire un URI, registrarlo in URItoKind, definire le astrazioni usando Kind<F, A> e fornire istanze per ogni URI. Questo è l'intero insieme di strumenti alla base delle librerie funzionali generiche in TypeScript.

Verifichi la sua comprensione del modello HKT leggero.

Ha assemblato il modello HKT leggero.

• La defunzionalizzazione sostituisce l'applicazione di funzioni di tipo con una ricerca.
• Kind<F, A> risolve un URI più un argomento in un tipo concreto.
• Le firme generiche usano Kind al posto di F<A>.
• Il modello si estende a due argomenti tramite Kind2 ed è la convenzione di fp-ts.

Prossimo argomento: un map generico con istanze reali.