Kehittyneiden abstraktioiden avaaminen: Syväsukellus TypeScriptin Higher-Kinded-tyyppeihin

Higher-Kinded-tyyppien emulointi TypeScriptissä

Koska TypeScriptistä puuttuu natiivi syntaksi HKT:ille, yhteisö on kehittänyt useita koodausstrategioita. Laajimmalle levinnyt ja testatuin lähestymistapa käyttää yhdistelmää rajapinnoista, tyyppihauista ja moduulilaajennuksista. Tämä on tekniikka, jota kuuluisa fp-ts-kirjasto käyttää.

URI- ja tyyppihakumenetelmä

Tämä menetelmä jakautuu kolmeen avainkomponenttiin:

1. Kind-tyyppi: Geneerinen kantajarajapinta edustamaan HKT-rakennetta.
2. URI:t: Uniikkeja merkkijonoliteraaleja tunnistamaan kukin tyyppikonstruktori.
3. URI-tyyppi-vastaavuus: Rajapinta, joka yhdistää merkkijono-URI:t niiden todellisiin tyyppikonstruktorimäärityksiin.

Rakennetaan se askel askeleelta.

Vaihe 1: `Kind`-rajapinta

Ensin määrittelemme perusrajapinnan, jota kaikki emuloidut HKT:mme noudattavat. Tämä rajapinta toimii sopimuksena.

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

            

              
                Copy
              
            
          

Puretaan tämä osiin:

Joskus tämä nähdään kirjoitettuna muodossa Kind. Nimeäminen ei ole kriittistä, mutta rakenne on.

Vaihe 2: URI-tyyppi-vastaavuus

Seuraavaksi tarvitsemme keskitetyn rekisterin kertomaan TypeScriptille, mitä konkreettista tyyppiä tietty URI vastaa. Saavutamme tämän rajapinnalla, jota voimme laajentaa moduulilaajennuksella.

            export interface URItoKind<A> {
  // Tämä täytetään eri moduuleissa
}

            

              
                Copy
              
            
          

Tämä rajapinta on tarkoituksellisesti jätetty tyhjäksi. Se toimii koukkuna. Jokainen moduuli, joka haluaa määritellä higher-kinded-tyypin, lisää siihen merkinnän.

Vaihe 3: `Kind`-aputyypin määrittely

Nyt luomme aputyypin, joka voi selvittää URI:n ja tyyppiparametrin takaisin konkreettiseksi tyypiksi.

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

            

              
                Copy
              
            
          

Vaihe 4: Tyypin rekisteröinti (esim. `Array`)

Jotta järjestelmämme olisi tietoinen sisäänrakennetusta Array-tyypistä, meidän on rekisteröitävä se. Teemme tämän moduulilaajennuksella.

            // Tiedostossa kuten `Array.ts`

// Ensin, julista uniikki URI Array-tyyppikonstruktorille
export const URI = 'Array';
declare module './hkt' { // Olettaen, että HKT-määrittelymme ovat `hkt.ts`-tiedostossa
  interface URItoKind<A> {
    readonly [URI]: Array<A>;
  }
}

            

              
                Copy
              
            
          

Käydään läpi, mitä juuri tapahtui:

Nyt Kind-tyyppimme toimii Array:lle! Tyyppi Kind<'Array', number> ratkeaa TypeScriptin toimesta muotoon URItoKind['Array'], joka moduulilaajennuksemme ansiosta on Array. Olemme onnistuneesti koodanneet Array:n HKT:ksi.

Kaiken yhdistäminen: Geneerinen `map`-funktio

HKT-koodauksemme ollessa paikallaan, voimme vihdoin kirjoittaa unelmiemme abstraktin map-funktion. Funktio itsessään ei ole geneerinen; sen sijaan määrittelemme geneerisen rajapinnan nimeltä Functor, joka kuvaa minkä tahansa tyyppikonstruktorin, jonka yli voidaan mapata.

            // `Functor.ts`-tiedostossa
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
              
            
          

Tämä Functor-rajapinta on itsessään geneerinen. Se ottaa yhden tyyppiparametrin, F, joka on rajoitettu olemaan yksi rekisteröidyistä URI:istamme. Sillä on kaksi jäsentä:

• URI: Funktorin URI (esim. 'Array').
• map: Geneerinen metodi. Huomaa sen allekirjoitus: se ottaa Kind:n ja funktion, ja palauttaa Kind:n. Tämä on abstrakti map-funktiomme!

Nyt voimme tarjota konkreettisen instanssin tästä rajapinnasta Array:lle.

            // `Array.ts`-tiedostossa jälleen

import { Functor } from './Functor';

// ... edellinen Array HKT -määrittely

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

            

              
                Copy
              
            
          

Tässä luomme objektin array, joka toteuttaa Functor<'Array'>-rajapinnan. map-toteutus on yksinkertaisesti kääre natiivin Array.prototype.map-metodin ympärillä.

Lopuksi voimme kirjoittaa funktion, joka käyttää tätä abstraktiota:

            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);
  };
}

// Käyttö:
const numbers = [1, 2, 3];
const double = (n: number) => n * 2;

// Annamme array-instanssin saadaksemme erikoistuneen funktion
const mapForArray = doSomethingWithFunctor(array);
const doubledNumbers = mapForArray(numbers, double); // [2, 4, 6]

console.log(doubledNumbers); // Tyyppi päätellään oikein muotoon number[]

            

              
                Copy
              
            
          

Tämä toimii! Olemme luoneet funktion doSomethingWithFunctor, joka on geneerinen säiliötyypin F yli. Se ei tiedä, työskenteleekö se Array:n, Promise:n vai Option:in kanssa. Se tietää vain, että sillä on Functor-instanssi kyseiselle säiliölle, mikä takaa map-metodin olemassaolon oikealla allekirjoituksella.

Käytännön sovellukset: Funktionaalisten abstraktioiden rakentaminen

Functor on vasta alkua. Ensisijainen motivaatio HKT:ille on rakentaa rikas hierarkia tyyppiluokkia (rajapintoja), jotka vangitsevat yleisiä laskennallisia malleja. Katsotaanpa kahta muuta olennaista: Applikatiivisia Funktoreita ja Monadeja.

Applikatiiviset Funktorit: Funktioiden soveltaminen kontekstissa

Funktorin avulla voit soveltaa normaalia funktiota arvoon kontekstin sisällä (esim. map(valueInContext, normalFunction)). Applikatiivinen Funktori (tai vain Applikatiivi) vie tämän askeleen pidemmälle: sen avulla voit soveltaa funktiota, joka on myös kontekstin sisällä, arvoon kontekstissa.

Applikatiivinen tyyppiluokka laajentaa Funktoria ja lisää kaksi uutta metodia:

1. of (tunnetaan myös nimellä `pure`): Ottaa normaalin arvon ja nostaa sen kontekstiin. Array:lle of(x) olisi [x]. Promise:lle of(x) olisi Promise.resolve(x).
2. ap: Ottaa säiliön, joka sisältää funktion `(a: A) => B`, ja säiliön, joka sisältää arvon `A`, ja palauttaa säiliön, joka sisältää arvon `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
              
            
          

Milloin tämä on hyödyllistä? Kuvittele, että sinulla on kaksi arvoa kontekstissa, ja haluat yhdistää ne kahden argumentin funktiolla. Esimerkiksi sinulla on kaksi lomakekenttää, jotka palauttavat Option:n (jossa Option on tyyppi, joka voi olla Some tai None).

            // Oletetaan, että meillä on Option-tyyppi ja sen Applikatiivi-instanssi

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

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

// Kuinka sovellamme create-User-funktiota nimeen ja ikään?

// 1. Nosta curry-funktio Option-kontekstiin
const curriedUserInOption = option.of(createUser);
// curriedUserInOption on tyyppiä Option<(name: string) => (age: number) => User>

// 2. `map` ei toimi suoraan. Tarvitsemme `ap`!
const userBuilderInOption = option.ap(option.map(curriedUserInOption, f => f), name);
// Tämä on kömpelöä. Parempi tapa:
const userBuilderInOption2 = option.map(name, createUser);
// userBuilderInOption2 on tyyppiä Option<(age: number) => User>

// 3. Sovella funktiota-kontekstissa ikään-kontekstissa
const userInOption = option.ap(userBuilderInOption2, age);
// userInOption on Some({ name: 'Alice', age: 30 })

            

              
                Copy
              
            
          

Tämä malli on uskomattoman tehokas esimerkiksi lomakkeiden validoinnissa, jossa useat itsenäiset validointifunktiot palauttavat tuloksen kontekstissa (kuten Either), ja haluat yhdistää kaikki tulokset. Applikatiivit mahdollistavat virheiden keräämisen kaikista validoinneista, kun taas seuraava abstraktio, Monadit, oikosulkisi ensimmäiseen virheeseen.

Monadit: Operaatioiden ketjuttaminen kontekstissa

Monadi on ehkä tunnetuin ja usein väärinymmärretty funktionaalinen abstraktio. Monadia käytetään operaatioiden ketjuttamiseen, joissa kukin vaihe riippuu edellisen tuloksesta, ja kukin vaihe palauttaa arvon käärittynä samaan kontekstiin.

Monadi-tyyppiluokka laajentaa Applikatiivia ja lisää yhden ratkaisevan metodin: chain (tunnetaan myös nimillä `flatMap` tai `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
              
            
          

Keskeinen ero map:n ja chain:n välillä on funktio, jonka ne hyväksyvät:

• map ottaa funktion (a: A) => B. Se soveltaa "normaalia" funktiota.
• chain ottaa funktion (a: A) => Kind. Se soveltaa funktiota, joka itsessään palauttaa arvon monadisessa kontekstissa.

chain estää sinua päätymästä sisäkkäisiin konteksteihin, kuten Promise> tai Option>. Se "litistää" tuloksen automaattisesti.

Klassinen esimerkki: Promiset

Olet todennäköisesti käyttänyt Monadeja tajuamatta sitä. Promise.prototype.then toimii monadisena chain:na (kun takaisinkutsu palauttaa toisen Promise:n).

            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!' });
}

// Ilman `chain` (`then`), saisit sisäkkäisen Promisen:
const nestedPromise: Promise<Promise<Post>> = getUser(1).then(user => {
  // Tämä `then` toimii tässä kuin `map`
  return getLatestPost(user); // palauttaa Promisen, luoden Promise<Promise<...>>
});

// Monadisella `chain`:lla (`then`, kun se litistää), rakenne on siisti:
const postPromise: Promise<Post> = getUser(1).then(user => {
  // `then` näkee, että palautimme Promisen ja litistää sen automaattisesti.
  return getLatestPost(user);
});

            

              
                Copy
              
            
          

HKT-pohjaisen Monadi-rajapinnan käyttäminen mahdollistaa sellaisten funktioiden kirjoittamisen, jotka ovat geneerisiä minkä tahansa peräkkäisen, kontekstitietoisen laskennan yli, olipa kyse sitten asynkronisista operaatioista (Promise), operaatioista, jotka voivat epäonnistua (Either, Option), tai laskennoista jaetulla tilalla (State).

HKT:iden tulevaisuus TypeScriptissä

Käsittelemämme emulointitekniikat ovat tehokkaita, mutta niihin liittyy kompromisseja. Ne tuovat mukanaan merkittävän määrän boilerplate-koodia ja jyrkän oppimiskäyrän. TypeScript-kääntäjän virheilmoitukset voivat olla kryptisiä, kun jokin menee pieleen koodauksessa.

Entä natiivi tuki? Pyyntö Higher-Kinded-tyypeille (tai jollekin mekanismille samojen tavoitteiden saavuttamiseksi) on yksi pisimpään jatkuneista ja eniten keskustelluista asioista TypeScriptin GitHub-repositoriossa. TypeScript-tiimi on tietoinen kysynnästä, mutta HKT:iden toteuttaminen asettaa merkittäviä haasteita:

1. Syntaktinen monimutkaisuus: Puhtaan, intuitiivisen syntaksin löytäminen, joka sopii hyvin olemassa olevaan tyyppijärjestelmään, on vaikeaa. Ehdotuksia, kuten type F tai F :: * -> *, on käsitelty, mutta jokaisella on etunsa ja haittansa.
2. Päättelyhaasteet: Tyyppipäättely, yksi TypeScriptin suurimmista vahvuuksista, muuttuu eksponentiaalisesti monimutkaisemmaksi HKT:iden kanssa. Sen varmistaminen, että päättely toimii luotettavasti ja suorituskykyisesti, on suuri este.
3. Yhdenmukaisuus JavaScriptin kanssa: TypeScript pyrkii olemaan yhdenmukainen JavaScriptin ajonaikaisen todellisuuden kanssa. HKT:t ovat puhtaasti käännösaikainen, tyyppitason konstruktio, mikä voi luoda käsitteellisen kuilun tyyppijärjestelmän ja alla olevan ajonaikaisen ympäristön välille.

Vaikka natiivi tuki ei ehkä olekaan välittömästi näköpiirissä, jatkuva keskustelu ja kirjastojen, kuten fp-ts, Effect ja ts-toolbelt, menestys todistavat, että käsitteet ovat arvokkaita ja sovellettavissa TypeScript-kontekstissa. Nämä kirjastot tarjoavat vankkoja, valmiiksi rakennettuja HKT-koodauksia ja rikkaan ekosysteemin funktionaalisia abstraktioita, säästäen sinut boilerplate-koodin kirjoittamiselta itse.

Yhteenveto: Uusi abstraktion taso

Higher-Kinded-tyypit edustavat merkittävää harppausta tyyppitason abstraktiossa. Ne antavat meille mahdollisuuden siirtyä geneerisyydestä tietorakenteidemme arvojen yli geneerisyyteen itse rakenteen yli. Abstrahoimalla säiliöiden, kuten Array, Promise, Option ja Either, yli voimme kirjoittaa universaaleja funktioita ja rajapintoja – kuten Funktori, Applikatiivi ja Monadi – jotka vangitsevat perustavanlaatuisia laskennallisia malleja.

Vaikka TypeScriptin natiivin tuen puute pakottaa meidät turvautumaan monimutkaisiin koodauksiin, hyödyt voivat olla valtavia kirjastojen tekijöille ja sovelluskehittäjille, jotka työskentelevät suurten, monimutkaisten järjestelmien parissa. HKT:iden ymmärtäminen antaa sinulle mahdollisuuden:

• Kirjoittaa uudelleenkäytettävämpää koodia: Määritellä logiikkaa, joka toimii mille tahansa tietorakenteelle, joka noudattaa tiettyä rajapintaa (esim. Functor).
• Parantaa tyyppiturvallisuutta: Pakottaa sopimuksia siitä, miten tietorakenteiden tulisi käyttäytyä tyyppitasolla, estäen kokonaisia bugiluokkia.
• Omaksua funktionaalisia malleja: Hyödyntää tehokkaita, hyväksi havaittuja malleja funktionaalisen ohjelmoinnin maailmasta sivuvaikutusten hallintaan, virheiden käsittelyyn ja deklaratiivisen, koostettavan koodin kirjoittamiseen.

Matka HKT:iden maailmaan on haastava, mutta se on palkitseva ja syventää ymmärrystäsi TypeScriptin tyyppijärjestelmästä sekä avaa uusia mahdollisuuksia puhtaan, vankan ja elegantin koodin kirjoittamiseen. Jos haluat viedä TypeScript-taitosi seuraavalle tasolle, fp-ts:n kaltaisten kirjastojen tutkiminen ja omien yksinkertaisten HKT-pohjaisten abstraktioiden rakentaminen on erinomainen paikka aloittaa.