Avdekking av avanserte abstraksjoner: En dybdeanalyse av TypeScripts Higher-Kinded Types

Emulering av Higher-Kinded Types i TypeScript

Siden TypeScript mangler en innebygd syntaks for HKT-er, har fellesskapet utviklet flere kodingsstrategier. Den mest utbredte og velprøvde tilnærmingen involverer en kombinasjon av grensesnitt, typeoppslag og modulutvidelse. Dette er teknikken som er kjent fra biblioteket fp-ts.

Metoden med URI og typeoppslag

Denne metoden kan deles inn i tre nøkkelkomponenter:

1. Kind-typen: Et generisk bærergrensesnitt for å representere HKT-strukturen.
2. URI-er: Unike streng-literaler for å identifisere hver typekonstruktør.
3. En URI-til-type-mapping: Et grensesnitt som kobler streng-URI-ene til deres faktiske typekonstruktør-definisjoner.

La oss bygge det steg for steg.

Steg 1: `Kind`-grensesnittet

Først definerer vi et basisgrensesnitt som alle våre emulerte HKT-er vil følge. Dette grensesnittet fungerer som en kontrakt.

            export interface HKT<URI, A> {
  readonly _URI: URI;
  readonly _A: A;
}

            

              
                Copy
              
            
          

La oss analysere dette:

Noen ganger vil du se dette skrevet som Kind. Navngivningen er ikke kritisk, men strukturen er det.

Steg 2: URI-til-type-mappingen

Deretter trenger vi et sentralt register for å fortelle TypeScript hvilken konkret type en gitt URI tilsvarer. Vi oppnår dette med et grensesnitt som vi kan utvide ved hjelp av modulutvidelse.

            export interface URItoKind<A> {
  // Dette vil bli fylt ut av forskjellige moduler
}

            

              
                Copy
              
            
          

Dette grensesnittet er bevisst tomt. Det fungerer som en krok. Hver modul som ønsker å definere en 'higher-kinded type' vil legge til en oppføring i det.

Steg 3: Definere en `Kind` typehjelper

Nå lager vi en verktøytype som kan løse opp en URI og en typeparameter tilbake til en konkret type.

            export type Kind<URI extends keyof URItoKind<any>, A> = URItoKind<A>[URI];

            

              
                Copy
              
            
          

Steg 4: Registrere en type (f.eks. `Array`)

For å gjøre systemet vårt oppmerksom på den innebygde Array-typen, må vi registrere den. Vi gjør dette ved hjelp av modulutvidelse.

            // I en fil som `Array.ts`

// Først, deklarer en unik URI for Array-typekonstruktøren
export const URI = 'Array';
declare module './hkt' { // Antar at våre HKT-definisjoner er i `hkt.ts`
  interface URItoKind<A> {
    readonly [URI]: Array<A>;
  }
}

            

              
                Copy
              
            
          

La oss bryte ned hva som nettopp skjedde:

Nå fungerer vår Kind-type for Array! Typen Kind<'Array', number> vil bli løst opp av TypeScript som URItoKind['Array'], som, takket være vår modulutvidelse, er Array. Vi har vellykket kodet Array som en HKT.

Sette alt sammen: En generisk `map`-funksjon

Med vår HKT-koding på plass, kan vi endelig skrive den abstrakte map-funksjonen vi drømte om. Selve funksjonen vil ikke være generisk; i stedet vil vi definere et generisk grensesnitt kalt Functor som beskriver enhver typekonstruktør som kan mappes over.

            // I `Functor.ts`
import { HKT, Kind, URItoKind } from './hkt';

export interface Functor<F extends keyof URItoKind<any>> {
  readonly URI: F;
  readonly map: <A, B>(fa: Kind<F, A>, f: (a: A) => B) => Kind<F, B>;
}

            

              
                Copy
              
            
          

Dette Functor-grensesnittet er selv generisk. Det tar én typeparameter, F, som er begrenset til å være en av våre registrerte URI-er. Det har to medlemmer:

• URI: URI-en til funktoren (f.eks. 'Array').
• map: En generisk metode. Legg merke til signaturen: den tar en Kind og en funksjon, og returnerer en Kind. Dette er vår abstrakte map!

Nå kan vi gi en konkret instans av dette grensesnittet for Array.

            // I `Array.ts` igjen

import { Functor } from './Functor';

// ... tidligere Array HKT-oppsett

export const array: Functor<typeof URI> = {
  URI: URI,
  map: <A, B>(fa: Array<A>, f: (a: A) => B): Array<B> => fa.map(f)
};

            

              
                Copy
              
            
          

Her lager vi et objekt array som implementerer Functor<'Array'>. map-implementeringen er simpelthen en innpakning rundt den innebygde Array.prototype.map-metoden.

Til slutt kan vi skrive en funksjon som bruker denne abstraksjonen:

            function doSomethingWithFunctor<F extends keyof URItoKind<any>>(
  functor: Functor<F>
) {
  return <A, B>(fa: Kind<F, A>, f: (a: A) => B): Kind<F, B> => {
    return functor.map(fa, f);
  };
}

// Bruk:
const numbers = [1, 2, 3];
const double = (n: number) => n * 2;

// Vi sender array-instansen for å få en spesialisert funksjon
const mapForArray = doSomethingWithFunctor(array);
const doubledNumbers = mapForArray(numbers, double); // [2, 4, 6]

console.log(doubledNumbers); // Typen er korrekt avledet som number[]

            

              
                Copy
              
            
          

Dette fungerer! Vi har laget en funksjon doSomethingWithFunctor som er generisk over beholdertypen F. Den vet ikke om den jobber med en Array, en Promise eller en Option. Den vet bare at den har en Functor-instans for den beholderen, noe som garanterer eksistensen av en map-metode med riktig signatur.

Praktiske anvendelser: Bygging av funksjonelle abstraksjoner

Functor er bare begynnelsen. Den primære motivasjonen for HKT-er er å bygge et rikt hierarki av typeklasser (grensesnitt) som fanger opp vanlige beregningsmønstre. La oss se på to andre essensielle: Applikative Funktorer og Monader.

Applikative Funktorer: Anvende funksjoner i en kontekst

En Funktor lar deg anvende en vanlig funksjon på en verdi inne i en kontekst (f.eks. map(valueInContext, normalFunction)). En Applikativ Funktor (eller bare Applikativ) tar dette et skritt videre: den lar deg anvende en funksjon som også er inne i en kontekst på en verdi i en kontekst.

Den applikative typeklassen utvider Funktor og legger til to nye metoder:

1. of (også kjent som `pure`): Tar en vanlig verdi og løfter den inn i konteksten. For Array vil of(x) være [x]. For Promise vil of(x) være Promise.resolve(x).
2. ap: Tar en beholder som inneholder en funksjon `(a: A) => B` og en beholder som inneholder en verdi `A`, og returnerer en beholder som inneholder en verdi `B`.

            import { Functor } from './Functor';
import { Kind, URItoKind } from './hkt';

export interface Applicative<F extends keyof URItoKind<any>> extends Functor<F> {
  readonly of: <A>(a: A) => Kind<F, A>;
  readonly ap: <A, B>(fab: Kind<F, (a: A) => B>, fa: Kind<F, A>) => Kind<F, B>;
}

            

              
                Copy
              
            
          

Når er dette nyttig? Tenk deg at du har to verdier i en kontekst, og du vil kombinere dem med en funksjon med to argumenter. For eksempel, du har to skjemainndata som returnerer en `Option` (der `Option` er en type som kan være `Some` eller `None`).

            // Anta at vi har en Option-type og dens Applikative instans

const name: Option<string> = some('Alice');
const age: Option<number> = some(30);

const createUser = (name: string) => (age: number) => ({ name, age });

// Hvordan anvender vi createUser på name og age?

// 1. Løft den curried funksjonen inn i Option-konteksten
const curriedUserInOption = option.of(createUser);
// curriedUserInOption er av typen Option<(name: string) => (age: number) => User>

// 2. `map` fungerer ikke direkte. Vi trenger `ap`!
const userBuilderInOption = option.ap(option.map(curriedUserInOption, f => f), name);
// Dette er klønete. En bedre måte:
const userBuilderInOption2 = option.map(name, createUser);
// userBuilderInOption2 er av typen Option<(age: number) => User>

// 3. Anvend funksjonen-i-en-kontekst på alderen-i-en-kontekst
const userInOption = option.ap(userBuilderInOption2, age);
// userInOption er Some({ name: 'Alice', age: 30 })

            

              
                Copy
              
            
          

Dette mønsteret er utrolig kraftig for ting som skjemavalidering, der flere uavhengige valideringsfunksjoner returnerer et resultat i en kontekst (som `Either`), og du vil kombinere alle resultatene. Applikativer lar deg aggregere feil fra alle valideringer, mens den neste abstraksjonen, Monader, ville kortslutte ved den første feilen.

Monader: Sekvensering av operasjoner i en kontekst

Monaden er kanskje den mest berømte og ofte misforståtte funksjonelle abstraksjonen. En Monade brukes for å sekvensere operasjoner der hvert trinn avhenger av resultatet fra det forrige, og hvert trinn returnerer en verdi pakket inn i samme kontekst.

Monade-typeklassen utvider Applikativ og legger til én avgjørende metode: chain (også kjent som `flatMap` eller `bind`).

            import { Applicative } from './Applicative';
import { Kind, URItoKind } from './hkt';

export interface Monad<M extends keyof URItoKind<any>> extends Applicative<M> {
  readonly chain: <A, B>(fa: Kind<M, A>, f: (a: A) => Kind<M, B>) => Kind<M, B>;
}

            

              
                Copy
              
            
          

Hovedforskjellen mellom map og chain er funksjonen de aksepterer:

• map tar en funksjon (a: A) => B. Den anvender en "vanlig" funksjon.
• chain tar en funksjon (a: A) => Kind. Den anvender en funksjon som selv returnerer en verdi i den monadiske konteksten.

chain er det som forhindrer at du ender opp med nøstede kontekster som Promise> eller Option>. Den "flater ut" resultatet automatisk.

Et klassisk eksempel: Promises

Du har sannsynligvis brukt Monader uten å være klar over det. Promise.prototype.then fungerer som en monadisk chain (når tilbakekallingen returnerer en annen Promise).

            interface User { id: number; name: string; }
interface Post { userId: number; content: string; }

function getUser(id: number): Promise<User> {
  return Promise.resolve({ id, name: 'Bob' });
}

function getLatestPost(user: User): Promise<Post> {
  return Promise.resolve({ userId: user.id, content: 'Hello HKTs!' });
}

// Uten `chain` (`then`), ville du fått en nøstet Promise:
const nestedPromise: Promise<Promise<Post>> = getUser(1).then(user => {
  // Denne `then` fungerer som `map` her
  return getLatestPost(user); // returnerer en Promise, og skaper Promise<Promise<...>>
});

// Med monadisk `chain` (`then` når den flater ut), er strukturen ren:
const postPromise: Promise<Post> = getUser(1).then(user => {
  // `then` ser at vi returnerte en Promise og flater den automatisk ut.
  return getLatestPost(user);
});

            

              
                Copy
              
            
          

Å bruke et HKT-basert Monade-grensesnitt lar deg skrive funksjoner som er generiske over enhver sekvensiell, kontekstbevisst beregning, enten det er asynkrone operasjoner (Promise), operasjoner som kan feile (Either, Option), eller beregninger med delt tilstand (State).

Fremtiden for HKT-er i TypeScript

Emuleringsteknikkene vi har diskutert er kraftige, men kommer med kompromisser. De introduserer en betydelig mengde standardkode og en bratt læringskurve. Feilmeldingene fra TypeScript-kompilatoren kan være kryptiske når noe går galt med kodingen.

Så, hva med innebygd støtte? Forespørselen om Higher-Kinded Types (eller en mekanisme for å oppnå de samme målene) er et av de eldste og mest diskuterte problemene på TypeScript sitt GitHub-repository. TypeScript-teamet er klar over etterspørselen, men implementering av HKT-er medfører betydelige utfordringer:

1. Syntaktisk kompleksitet: Å finne en ren, intuitiv syntaks som passer godt med det eksisterende typesystemet er vanskelig. Forslag som type F eller F :: * -> * har blitt diskutert, men hver har sine fordeler og ulemper.
2. Inferensutfordringer: Typeinferens, en av TypeScripts største styrker, blir eksponentielt mer kompleks med HKT-er. Å sikre at inferens fungerer pålitelig og ytelsesmessig er en stor hindring.
3. Samsvar med JavaScript: TypeScript har som mål å være i tråd med JavaScripts kjøretidsvirkelighet. HKT-er er en ren kompileringstids-, typenivå-konstruksjon, noe som kan skape et konseptuelt gap mellom typesystemet og den underliggende kjøretiden.

Selv om innebygd støtte kanskje ikke er i umiddelbar horisont, beviser den pågående diskusjonen og suksessen til biblioteker som fp-ts, Effect, og ts-toolbelt at konseptene er verdifulle og anvendelige i en TypeScript-kontekst. Disse bibliotekene tilbyr robuste, ferdigbygde HKT-kodinger og et rikt økosystem av funksjonelle abstraksjoner, noe som sparer deg for å skrive standardkoden selv.

Konklusjon: Et nytt nivå av abstraksjon

Higher-Kinded Types representerer et betydelig sprang i typenivå-abstraksjon. De lar oss gå fra å være generiske over verdiene i våre datastrukturer til å være generiske over selve strukturen. Ved å abstrahere over beholdere som Array, Promise, Option og Either, kan vi skrive universelle funksjoner og grensesnitt – som Funktor, Applikativ og Monade – som fanger opp grunnleggende beregningsmønstre.

Selv om TypeScripts mangel på innebygd støtte tvinger oss til å stole på komplekse kodinger, kan fordelene være enorme for bibliotekforfattere og applikasjonsutviklere som jobber med store, komplekse systemer. Å forstå HKT-er gjør deg i stand til å:

• Skrive mer gjenbrukbar kode: Definer logikk som fungerer for enhver datastruktur som samsvarer med et spesifikt grensesnitt (f.eks. `Functor`).
• Forbedre typesikkerheten: Håndhev kontrakter for hvordan datastrukturer skal oppføre seg på typenivå, og forhindre hele klasser av feil.
• Omfavne funksjonelle mønstre: Utnytt kraftige, velprøvde mønstre fra den funksjonelle programmeringsverdenen for å håndtere bivirkninger, feil og skrive deklarativ, komponerbar kode.

Reisen inn i HKT-er er utfordrende, men det er en givende reise som utdyper din forståelse av TypeScripts typesystem og åpner opp nye muligheter for å skrive ren, robust og elegant kode. Hvis du ønsker å ta dine TypeScript-ferdigheter til neste nivå, er utforsking av biblioteker som fp-ts og bygging av dine egne enkle HKT-baserte abstraksjoner et utmerket sted å starte.