TypeScript 45 🔷 Higher-Kinded Type Patterns - KandZ

TypeScript does not have higher-kinded types. This is a fact, not a limitation of your understanding. Higher-kinded types — the ability to abstract over a type constructor itself, as in F<T> where F is a parameter — are present in Haskell, Scala, and Rust (via traits and associated types), but they were never added to TypeScript. The language has generics, so you can write Array<T>, Promise<T>, and Map<K, V>, but you cannot write a generic function that accepts Array or Promise as a parameter and applies it to a type. Array is not a type — it is a type constructor, a function from types to types. TypeScript’s type system only quantifies over types, not over type constructors. The practical consequence is that patterns which would be one line in Haskell become workarounds in TypeScript. This chapter covers what higher-kinded types are, why they matter, the emulation tricks TypeScript developers use, and when those tricks are worth the complexity. It is an advanced topic, and much of the time the honest answer is: you do not need this. But knowing what it is and why TypeScript lacks it helps you recognize when you are fighting the language and when there is a clean encoding.

Key point: A higher-kinded type abstracts over a type constructor — something like Array or Promise that takes a type and produces a type. TypeScript can abstract over types (<T>(x: T) => T), but not over type constructors (<F>(x: F<number>) => F<string> is not legal). The standard emulation uses a registry interface mapping names to type constructors, plus an Apply helper that looks up the constructor and applies it. This encoding works but requires declaration merging for each constructor and has real limitations — inference is weaker, and the registry must be maintained. For most code, a plain generic or an overloaded function is simpler and clearer.

What higher-kinded types are

A kind is the “type of a type.” Ordinary types like string and number have kind * — they are fully applied and describe values. Type constructors like Array and Promise have kind * -> * — they take a type and produce a type. Array alone is not a type; Array<string> is. A higher-kinded type system lets you abstract over type constructors themselves, so a function or interface can say “for any F of kind * -> *, do something.”

Why this matters in practice. Consider a functor — a container that supports mapping over its contents. Arrays are functors (map exists), promises are functors (then exists), and Option-like types are functors. In Haskell, you write one fmap that works for all of them:

fmap :: Functor f => (a -> b) -> f a -> f b

The f is a type constructor parameter. In TypeScript, you cannot write the equivalent:

// This is not valid TypeScript
function fmap<F, A, B>(f: (a: A) => B, fa: F<A>): F<B> {
  // ...
}

F<A> is a syntax error because F is not a type — it is a type constructor, and TypeScript has no syntax for that. You can write fmap for arrays, and a separate one for promises, and a separate one for Option, but you cannot unify them under one generic signature.

Why TypeScript lacks HKT. Adding higher-kinded types would require a significant extension to the type system: kinds, kind inference, higher-kinded quantification, and the machinery to check that F is applied to the right number of arguments. The TypeScript team has repeatedly deferred this, citing complexity, performance, and the observation that most real TypeScript code does not need it. The language instead relies on structural typing and concrete generics, which cover the vast majority of cases.

What people do instead. They emulate HKT with a registry. The idea is to represent type constructors as entries in an interface, keyed by a name, and provide an Apply type that looks up a constructor and applies it. This is the encoding used by libraries like fp-ts and Effect. It works, but it is verbose and inference is limited.

Why the emulation is not really HKT. In a true HKT system, F is a genuine parameter that can be instantiated with any type constructor, including ones the compiler has never seen. In the emulation, F is a key into a registry that must be populated by declaration merging before use. Adding a new constructor means editing the registry. The abstraction leaks: it is not open in the way real HKT is.

The registry-and-Apply encoding

The standard emulation has three parts: a URItoKind interface that maps names to type constructors, a URI union of those names, and an Apply type that resolves a name to a concrete type.

interface URItoKind<A> {
  Array: Array<A>;
  Promise: Promise<A>;
}

type URIS = keyof URItoKind<unknown>;

type Apply<F extends URIS, A> = URItoKind<A>[F];

URItoKind<A> is a map from the name "Array" to the type Array<A>, and from "Promise" to Promise<A>. The Apply type indexes into this map with F to get the concrete type. Apply<"Array", string> resolves to Array<string>, and Apply<"Promise", number> resolves to Promise<number>.

Using the encoding. With Apply in place, you can write generic functions that abstract over the container.

function lift<F extends URIS, A>(fa: Apply<F, A>): Apply<F, A[]> {
  return [fa] as any; // simplified for illustration
}

The F parameter is a URI string, and Apply<F, A> is the container applied to A. This compiles, and it approximates the HKT pattern, but it requires a cast inside the implementation because the compiler cannot verify the body.

Declaration merging for extensibility. New constructors are added by merging into URItoKind.

interface URItoKind<A> {
  Option: Option<A>;
}

interface Option<A> {
  _tag: "Some" | "None";
  value: A;
}

After this merge, Apply<"Option", string> resolves to Option<string>. The registry grows by declaration merging, and the URIS union picks up the new key automatically because it is keyof URItoKind<unknown>.

Why the encoding is verbose. Every new container requires a registry entry, an interface, and often a helper. The any cast inside implementations is a constant reminder that the type system is not truly verifying the abstraction. This is the price of emulating a feature the language does not have.

Why `URItoKind` needs a type parameter

The URItoKind<A> interface is parameterized by A because the constructors are generic. Array takes an element type, so the map entry must be Array<A> where A is the parameter. This means each lookup applies the constructor to a specific A, which is exactly what Apply does.

Why one parameter is not always enough. Some constructors take two type parameters — Map<K, V>, Either<E, A>, Result<T, E>. The simple registry handles only one parameter. For two-parameter constructors, the encoding needs a second registry or a way to partially apply.

interface URItoKind2<E, A> {
  Either: Either<E, A>;
  Result: Result<E, A>;
}

type Apply2<F extends keyof URItoKind2<unknown, unknown>, E, A> =
  URItoKind2<E, A>[F];

The two-parameter case gets its own registry and its own Apply2. This is the pattern fp-ts uses: URItoKind, URItoKind2, URItoKind3, and so on. Each arity needs its own machinery.

Why partial application is the hard part. In real HKT, you can partially apply a constructor: Either<E, _> is a type constructor waiting for one more argument. TypeScript has no syntax for partial application of a generic type. The workaround is to define a specialized type that fixes the first parameter:

type EitherE<E> = {
  kind: "Either";
  errorType: E;
};

This is not the same thing — it is a marker, not a genuine partial application — but it lets the registry key distinguish Either<string, _> from Either<number, _>. The complexity grows quickly.

When the emulation is worth it

The HKT emulation is a real tool with real use cases, but it is heavy. Knowing when to reach for it and when to avoid it is more important than knowing the encoding itself.

When it pays off:

You are building a library whose entire purpose is abstraction over containers — fp-ts, Effect, io-ts, and similar
You have many operations (map, flatMap, traverse, sequence) that must work uniformly across many containers
The abstraction is the product, and users will bring their own containers
You control the registry and can document the merging requirement

When it is overkill:

You have two or three containers, and separate functions for each would be clearer
The abstraction is internal to one application, not exposed to users
You are the only consumer, and you know the concrete types
Inference matters more than uniformity — the emulation weakens inference significantly

The pragmatic alternative. For most code, write the operation once per container or once per concrete type. A mapArray, a mapPromise, and a mapOption are three functions, each of which type-checks fully and infers correctly. The HKT version is one function with an any cast inside and weakened inference. The duplication is often the better trade.

Why functional programming libraries still use it. Because their entire reason for existing is uniformity across containers. fp-ts users expect map to work on Option, Either, Task, Reader, and everything else, with the same signature. That uniformity justifies the machinery. For application code that uses one or two containers, it does not.

Complete Example Session

// ============================================
// PART 1: THE LIMITATION
// ============================================

// This is not valid TypeScript:
// function fmap<F, A, B>(f: (a: A) => B, fa: F<A>): F<B> { ... }

// You can write concrete versions:
function mapArray<A, B>(f: (a: A) => B, fa: A[]): B[] {
  return fa.map(f);
}

function mapPromise<A, B>(f: (a: A) => B, fa: Promise<A>): Promise<B> {
  return fa.then(f);
}

// But you cannot unify them under one signature.

// ============================================
// PART 2: THE REGISTRY
// ============================================

interface URItoKind<A> {
  Array: Array<A>;
  Promise: Promise<A>;
}

type URIS = keyof URItoKind<unknown>;

type Apply<F extends URIS, A> = URItoKind<A>[F];

// ============================================
// PART 3: APPLY IN ACTION
// ============================================

type A1 = Apply<"Array", string>;     // string[]
type A2 = Apply<"Promise", number>;   // Promise<number>

// ============================================
// PART 4: A GENERIC FUNCTION
// ============================================

function lift<F extends URIS, A>(fa: Apply<F, A>): Apply<F, A[]> {
  // The cast is required; the compiler cannot verify the body.
  return [fa] as Apply<F, A[]>;
}

// ============================================
// PART 5: EXTENDING THE REGISTRY
// ============================================

interface Option<A> {
  _tag: "Some" | "None";
  value: A;
}

interface URItoKind<A> {
  Option: Option<A>;
}

// URIS now includes "Option" automatically.
type A3 = Apply<"Option", string>; // Option<string>

// ============================================
// PART 6: TWO-PARAMETER CONSTRUCTORS
// ============================================

interface Either<E, A> {
  _tag: "Left" | "Right";
  value: E | A;
}

interface URItoKind2<E, A> {
  Either: Either<E, A>;
}

type Apply2<F extends keyof URItoKind2<unknown, unknown>, E, A> =
  URItoKind2<E, A>[F];

type A4 = Apply2<"Either", string, number>; // Either<string, number>

// ============================================
// PART 7: THE COST — WEAK INFERENCE
// ============================================

// The compiler infers F from the argument, but only from the registry.
// It cannot infer F from an arbitrary container type the way real HKT would.

// ============================================
// PART 8: THE ALTERNATIVE — CONCRETE FUNCTIONS
// ============================================

// For a small number of containers, this is clearer:

function mapOption<A, B>(f: (a: A) => B, o: Option<A>): Option<B> {
  return o._tag === "Some"
    ? { _tag: "Some", value: f(o.value) }
    : { _tag: "None", value: undefined as never };
}

// ============================================
// PART 9: WHEN THE EMULATION EARNS ITS KEEP
// ============================================

// Uniform operations across many containers:
// - map, flatMap, traverse, sequence, chain
// - Each works the same way regardless of container
// - Users bring their own containers via declaration merging

// ============================================
// PART 10: WHAT NOT TO DO
// ============================================

// Do not reach for HKT emulation for two or three containers.
// Write concrete functions; they infer better and read better.

// Do not assume the emulation is sound.
// The `any` cast inside implementations is a real hole.

// Do not try to infer F from a container argument.
// The registry must be populated; inference is limited.

Each part isolates one aspect. Parts 1 through 5 show the basic encoding, parts 6 and 7 show the two-parameter case and the inference cost, and parts 8 through 10 show the alternative and the boundaries.

Quick Reference

What TypeScript Has vs Lacks

Feature	Available
Generic over a type	✅ `<T>(x: T) => T`
Generic over a type constructor	❌ `<F>(x: F<number>) => F<string>`
Partial application of a generic	❌
Kind annotation	❌
HKT emulation via registry	✅ (with limitations)

The Encoding

Piece	Purpose
`URItoKind<A>`	Map names to constructors
`URIS`	Union of names
`Apply<F, A>`	Resolve a name to a concrete type
Declaration merging	Add new constructors
`URItoKind2<E, A>`	Two-parameter constructors
`Apply2<F, E, A>`	Two-parameter application

Emulation vs Concrete

Aspect	Emulation	Concrete
Uniformity	✅	❌
Inference	⚠️ Weak	✅ Strong
Soundness	⚠️ `any` cast inside	✅
Setup cost	High	Low
Best for	Libraries over many containers	Application code

Libraries Using the Encoding

Library	Purpose
`fp-ts`	Functional programming abstractions
`Effect`	Effect system with HKT-like abstraction
`io-ts`	Runtime type validation
`fp-ts-contrib`	Additional HKT utilities

When to Use

Situation	Use HKT emulation?
Library abstracting over many containers	✅
Application with 2–3 containers	❌
One container	❌
Inference-critical code	❌
User-extensible abstraction	✅

Best Practices

✅ Do This:

// Use concrete functions when there are few containers
function mapArray<A, B>(f: (a: A) => B, fa: A[]): B[] {
  return fa.map(f);
}                                                              // ✅

// Use the registry encoding only when uniformity is the product
interface URItoKind<A> { Array: Array<A>; Promise: Promise<A>; } // ✅

// Keep the registry in one file, documented
// Add constructors via declaration merging                    // ✅

// Prefer the library's encoding over hand-rolling it
// fp-ts and Effect already solve this                          // ✅

// Name the cast site and comment it
return [fa] as Apply<F, A[]>; // compiler cannot verify        // ✅

❌ Don’t Do This:

// Don't write <F, A> F<A> — it is not valid
// function fmap<F, A, B>(...) { }                              // ⚠️

// Don't reach for HKT for two containers
// Write two functions instead                                  // ⚠️

// Don't assume inference works like real HKT
// F must be inferable from the registry                        // ⚠️

// Don't scatter `any` casts silently
// Each is a hole in the type system                            // ⚠️

// Don't emulate partial application with markers unless needed
// It adds complexity that rarely pays off                      // ⚠️

Common Pitfalls

Pitfall	Problem	Solution
Writing `F<A>` directly	Not valid syntax	Use `Apply<F, A>`
Forgetting to merge registry	`Apply` fails to resolve	Add to `URItoKind`
Weak inference	`F` not inferred from argument	Annotate `F` explicitly
Two-parameter constructors	No registry entry	Use `URItoKind2`
Cast inside implementation	Unsound body	Acknowledge the hole
Overusing for small code	Complexity exceeds benefit	Use concrete functions
Partial application	No native support	Use marker types
Assuming soundness	HKT emulation is not real HKT	Treat as best-effort

Real-World Examples

1. Concrete map functions

function mapArray<A, B>(f: (a: A) => B, fa: A[]): B[] {
  return fa.map(f);
}

2. Registry for arrays and promises

interface URItoKind<A> {
  Array: Array<A>;
  Promise: Promise<A>;
}

3. `Apply` helper

type Apply<F extends URIS, A> = URItoKind<A>[F];

4. Extending the registry

interface URItoKind<A> {
  Option: Option<A>;
}

5. Two-parameter registry

interface URItoKind2<E, A> {
  Either: Either<E, A>;
}

6. `Apply2`

type Apply2<F extends keyof URItoKind2<unknown, unknown>, E, A> =
  URItoKind2<E, A>[F];

7. Option type

interface Option<A> {
  _tag: "Some" | "None";
  value: A;
}

8. Concrete option map

function mapOption<A, B>(f: (a: A) => B, o: Option<A>): Option<B> {
  return o._tag === "Some"
    ? { _tag: "Some", value: f(o.value) }
    : { _tag: "None", value: undefined as never };
}

9. Using `fp-ts` instead of hand-rolling

import { map } from "fp-ts/Array";

10. Type-level `Apply` for inference

function lift<F extends URIS, A>(fa: Apply<F, A>): Apply<F, A[]> {
  return [fa] as Apply<F, A[]>;
}

Visual: Kinds

┌──────────────────────────────────────────────┐
│  KIND * (types of values)                    │
│                                              │
│    string      number      boolean           │
│    { x: 1 }   [1, 2, 3]    null              │
│                                              │
├──────────────────────────────────────────────┤
│  KIND * -> * (type constructors)             │
│                                              │
│    Array<T>       Promise<T>                 │
│    Option<T>      Either<E, A>               │
│                                              │
│  These are not types until applied.          │
│  Array alone is not a type; Array<string> is.│
│                                              │
├──────────────────────────────────────────────┤
│  HKT — abstracting over * -> *               │
│                                              │
│    fmap<F, A, B>(f, F<A>) -> F<B>            │
│                                              │
│  TypeScript: ❌ not supported                │
│                                              │
└──────────────────────────────────────────────┘

Visual: The Registry Encoding

┌──────────────────────────────────────────────┐
│  interface URItoKind<A> {                    │
│    Array:   Array<A>;                        │
│    Promise: Promise<A>;                      │
│    Option:  Option<A>;                       │
│  }                                           │
│                                              │
│         ┌──────────────────────┐             │
│  F ────►│  URItoKind lookup    │────► type   │
│         └──────────────────────┘             │
│                                              │
│  Apply<"Array", string>  →  string[]         │
│  Apply<"Option", number> →  Option<number>   │
│                                              │
│  The name F indexes the map.                 │
│  The map entry applies the constructor.      │
│                                              │
└──────────────────────────────────────────────┘

Visual: Real HKT vs Emulation

┌──────────────────────────────────────────────┐
│  REAL HKT (Haskell, Scala)                   │
│                                              │
│    fmap :: Functor f => (a -> b)             │
│              -> f a -> f b                   │
│                                              │
│  f is a genuine parameter.                   │
│  Any constructor can be used.                │
│  Inference works.                            │
│  Open — new constructors need no registry.   │
│                                              │
└──────────────────────────────────────────────┘

┌──────────────────────────────────────────────┐
│  EMULATION (TypeScript)                      │
│                                              │
│    function fmap<F extends URIS, A, B>(...)  │
│                                              │
│  F is a string key into a registry.          │
│  Only registered constructors work.          │
│  Inference is limited.                       │
│  Closed — new constructors need merging.     │
│  `any` cast inside implementations.          │
│                                              │
└──────────────────────────────────────────────┘

Visual: When to Reach for the Encoding

┌──────────────────────────────────────────────┐
│  How many containers?                        │
│                                              │
│       1           2-3           many         │
│       │            │              │          │
│       ▼            ▼              ▼          │
│   concrete    concrete      HKT emulation    │
│   function    functions     (or a library)   │
│                                              │
│  Is the abstraction the product?             │
│       │                                      │
│       ├── No  ──► concrete functions         │
│       │                                      │
│       └── Yes ──► HKT emulation              │
│                   (or use fp-ts / Effect)    │
│                                              │
└──────────────────────────────────────────────┘

Summary

Item	Value
HKT in TypeScript	Not supported
Abstraction over types	✅ Generics
Abstraction over type constructors	❌
Emulation	Registry + `Apply`
Registry	`URItoKind<A>`
Lookup	`Apply<F, A>`
Extension	Declaration merging
Two-parameter	`URItoKind2<E, A>`
Cost	Weak inference, `any` casts
Best for	Libraries over many containers
Alternative	Concrete functions per container

Key takeaways:

TypeScript does not have higher-kinded types — you cannot abstract over a type constructor like Array or Promise
A higher-kinded type abstracts over type constructors, not over types, and TypeScript only supports the latter
The standard emulation uses a registry (URItoKind) plus an Apply helper that looks up a constructor and applies it
New constructors are added via declaration merging, and the URIS union picks them up automatically
Two-parameter constructors need a second registry — URItoKind2 and Apply2
The emulation weakens inference and requires any casts inside implementations, which is a real cost
For a small number of containers, concrete functions are clearer, faster, and sound — write mapArray, mapPromise, mapOption separately
The emulation earns its keep in libraries whose entire purpose is uniformity across many containers — fp-ts, Effect, and similar
Know when you are fighting the language — if you are hand-rolling HKT for three containers, you are probably writing more machinery than the problem deserves

Remember: Higher-kinded types are a real feature in some languages and a genuine gap in TypeScript. The registry encoding bridges the gap, but it is a workaround, not a solution — inference is weaker, the registry must be maintained, and implementations rely on casts. Use it when the abstraction is the product. Otherwise, write concrete functions and move on.

Stop using slow, ad-bloated tool sites! 🤮

🔎 Search “KandZ Tools” on Google to use many professional utilities for free.

KandZ.me is the ultimate minimalist hub for:
✅ Finance (Mortgage, Interest, Inflation)
✅ Tech (Base64, JSON, Dev Suite, IP)
✅ Health (BMI, BMR, TDEE)
✅ Productivity (Timer, Workspace, QR)

⚡️ Fast & Private
🔒 No data leaves your device
💎 100% Free

🔗 Use it now: https://tools.kandz.me
🔖 Bookmark it—you’ll need it later!