Product, coproduct & exponential

Data structures, tuples/unions/functions

Publish at: 10 Nov 2025

 ____  ____   ___  ____  _   _  ____ _____ ____
|  _ \|  _ \ / _ \|  _ \| | | |/ ___|_   _/ ___|
| |_) | |_) | | | | | | | | | | |     | | \___ \
|  __/|  _ <| |_| | |_| | |_| | |___  | |  ___) |
|_|   |_| \_\\___/|____/ \___/ \____| |_| |____( )
  ____ ___  ____  ____   ___  ____  _   _  ____|/____ ____
 / ___/ _ \|  _ \|  _ \ / _ \|  _ \| | | |/ ___|_   _/ ___|
| |  | | | | |_) | |_) | | | | | | | | | | |     | | \___ \
| |__| |_| |  __/|  _ <| |_| | |_| | |_| | |___  | |  ___) |
 \____\___/|_| __|_| \_\\___/|____/ \___/ \____| |_| |____/
   / \  | \ | |  _ \
  / _ \ |  \| | | | |
 / ___ \| |\  | |_| |
/_/___\_\_|_\_|____/__  _   _ _____ _   _ _____ ___    _    _     ____
| ____\ \/ /  _ \ / _ \| \ | | ____| \ | |_   _|_ _|  / \  | |   / ___|
|  _|  \  /| |_) | | | |  \| |  _| |  \| | | |  | |  / _ \ | |   \___ \
| |___ /  \|  __/| |_| | |\  | |___| |\  | | |  | | / ___ \| |___ ___) |
|_____/_/\_\_|    \___/|_| \_|_____|_| \_| |_| |___/_/   \_\_____|____/

So-far, we have learned how to deal with morphisms, what they are and how to organize them in hom-sets. But what about the other element of the category - objects? There is a classification for them as well. It is difficult to deal with every object every time we create new structures to solve problems. Essentially, we are looking for ways to combine objects into a family or choose one object among different families.

Formal definition #

Product #

A product^[1] of objects A and B in a category C is an object A × B together with two projection^[2] morphisms:

π₁: A × B -> A (first projection) - extracts the first component:

Given a pair in A × B, it gives you the A part
π₂: A × B -> B (second projection) - extracts the second component:

Given a pair in A × B, it gives you the B part such that for any object X and morphisms f: X -> A and g: X -> B, there exists a unique morphism ⟨f, g⟩: X -> A × B making the following diagram commute.

                    f
            X ------------> A
            │             ↗
            │            ╱
     ⟨f,g⟩  │           ╱   π₁ (first projection)
  (pairing) │          ╱
            ↓         ╱
           A x B ----╱
            │
            │ π₂ (second projection)
            |
            ↓     g
            B <--------X

Universal Property:
• π₁ ∘ ⟨f,g⟩ = f  (going X -> A × B -> A equals going X -> A directly)
• π₂ ∘ ⟨f,g⟩ = g  (going X -> A × B -> B equals going X -> B directly)
• ⟨f,g⟩ is the UNIQUE morphism making this work

Commute in this case means that all possible paths between any two objects give the same result. In other words, if you can go from object X to object A by two different routes through the diagram, both routes must be equivalent (compose to the same morphism).

Or using math notation:

∀X ∈ Ob(C),
∀f ∈ Hom(X, A),
∀g ∈ Hom(X, B),
∃! ⟨f, g⟩ ∈ Hom(X, A × B)

such that:

π₁ ∘ ⟨f, g⟩ = f
π₂ ∘ ⟨f, g⟩ = g

The diagram commutes because there are two ways to get from X to A, and they must give the same result:

Direct path: f(X) -> A
Indirect path: ⟨f,g⟩(X) -> A × B, π₁(A × B) -> A

Where: f = π₁ ∘ ⟨f,g⟩

Similarly for X to B:

Direct path: g(X) -> B
Indirect path: ⟨f,g⟩(X) -> A × B, π₂(A × B) -> B

Where: g = π₂ ∘ ⟨f,g⟩

This is what makes the product universal - it captures both relationships through a single morphism ⟨f,g⟩.

π₁ ∘ ⟨f, g⟩ = f
π₂ ∘ ⟨f, g⟩ = g
⟨f, g⟩ is the unique morphism with this property

Coproduct #

A coproduct of objects A and B in a category C is an object A + B together with two injection morphisms: ^[3]

ι₁: A -> A + B (first injection)
ι₂: B -> A + B (second injection)

such that for any object X and morphisms f: A -> X and g: B -> X, there exists a unique morphism [f, g]: A + B -> X making the following diagram commute:

     A -----> X <---- B
     │       ↗      ↙ │
  ι₁ │     f     g    │ ι₂
     │   ↙        ↖   │
     ↓ ↙            ↖ ↓
    A + B -----------> X
           [f,g]

Commute in this case means the same thing: all possible paths between any two objects must give the same result.

Or using math notation:

∀X ∈ Ob(C),
∀f ∈ Hom(A, X),
∀g ∈ Hom(B, X),
∃! [f, g] ∈ Hom(A + B, X)

such that:

[f, g] ∘ ι₁ = f
[f, g] ∘ ι₂ = g

From A to X:

Direct path: f(A) -> X
Indirect path: ι₁(A) -> A + B, [f,g](A + B) -> X

Commutation requirement: f = [f,g] ∘ ι₁

From B to X:

Direct path: g(B) -> X
Indirect path: ι₂(B) -> A + B, [f,g](A + B) -> X

Commutation requirement: g = [f,g] ∘ ι₂

The coproduct [f,g]: A + B -> X is called case analysis morphism that:

When given something that came from A (via ι₁), applies function f
When given something that came from B (via ι₂), applies function g

[f, g] ∘ ι₁ = f
[f, g] ∘ ι₂ = g
[f, g]` is the *unique* morphism with this property

Exponential Object #

(Function Types)

An exponential object or function object from A to B in a category C is an object B^A together with an evaluation morphism: ^[5]

eval: B^A × A -> B (evaluation morphism) - applies a function to its argument

such that for any object X and morphism f: X × A -> B, there exists a unique morphism curry(f): X -> B^A making the following diagram commute:

Function Application:

    B^A × A ---------> B
      ^               ^
      |              /
curry(f) × id_A     / eval
      |            /
      |           /
    X × A -------/
            f

Universal Property:

eval ∘ (curry(f) × id_A) = f
curry(f) is the UNIQUE morphism making this work

Or using math notation:

∀X ∈ Ob(C),
∀f ∈ Hom(X × A, B),
∃! curry(f) ∈ Hom(X, B^A)

such that:

eval ∘ (curry(f) × id_A) = f

Evaluation morphism #

Evaluation morphism - eval takes a pair consisting of:

A function from A to B (represented as B^A)
An argument of type A

And produces a result of type B by applying the function to the argument. Think of eval as the categorical way to represent "function application" or "calling a function":

// In programming terms, eval does this:
function _eval<A, B>(func: (a: A) => B, arg: A): B {
  return func(arg);  // Apply function to argument
}

// So if you have:
const add5 = (x: number) => x + 5;  // This is B^A where A=number, B=number
const argument = 3;                 // This is A

_eval(add5, 3);                     // This is B

The eval morphism is crucial because it enables the currying isomorphism:

Hom(X × A, B) ≅ Hom(X, B^A)

This isomorphism works through two operations:

Currying: f: X × A -> B becomes curry(f): X -> B^A. Every morphism f: X × A -> B corresponds to exactly one morphism curry(f): X -> B^A.
Uncurrying: g: X -> B^A becomes uncurry(g): X × A -> B. Every morphism g: X -> B^A corresponds to exactly one morphism uncurry(g): X × A -> B

Isomorphism is this case means - curry and uncurry are inverse operations

The eval morphism is what makes uncurrying work:

uncurry(g) = eval ∘ (g × id_A)

The universal property states that for any morphism f: X × A -> B, there exists a unique curry(f): X -> B^A such that:

eval ∘ (curry(f) × id_A) = f

This means:

Start with (x, a) where x: X and a: A
Apply curry(f) × id_A to get (curry(f)(x), a)
Apply eval to get the same result as f(x, a)

eval - "function application", the most basic operation in functional programming and lambda calculus.

The exponential captures the essence of function abstraction:

Currying: Transforms f: X × A -> B into curry(f): X -> B^A
Application: Uses eval: B^A × A -> B to apply functions to arguments
Lambda Abstraction: B^A represents "functions from A to B"

Exponentials complete the fundamental ways to combine objects:

Products: AND - you need both A AND B
Coproducts: OR - you have either A OR B
Exponentials: IMPLIES - functions from A to B

Key Properties #

Uniqueness

Both products and coproducts are unique up to isomorphism. If two objects satisfy the universal property, they are isomorphic.

Product:

For any object X and morphisms f: X -> A and g: X -> B, there exists a unique morphism ⟨f,g⟩: X -> A × B such that π₁ ∘ ⟨f,g⟩ = f and π₂ ∘ ⟨f,g⟩ = g

Coproduct:

For any object X and morphisms f: A -> X and g: B -> X, there exists a unique morphism [f,g]: A + B -> X such that [f,g] ∘ ι₁ = f and [f,g] ∘ ι₂ = g
Existence

Not every category has products, coproducts, or exponentials for all objects. Common existence assumptions:
- Categories with finite products: Have products for any finite collection of objects
- Categories with finite coproducts: Have coproducts for any finite collection of objects
Duality

Products and coproducts are categorical duals:
- The coproduct in category C is the product in the opposite category C^op
- All arrows are reversed between the two constructions
Products and coproducts are the same construction, but with all arrows reversed:
- Product: X -> A × B (multiple things going to one)
- Coproduct: A + B -> X (one thing coming from multiple)
Functoriality

Products and coproducts are functorial:
- Given morphisms f: A -> A' and g: B -> B', there exist induced morphisms:
  - (f × g): A × B -> A' × B' (product of morphisms)
  - (f + g): A + B -> A' + B' (coproduct of morphisms)

Product Morphisms #

Pairing Morphism:

For morphisms f: X -> A and g: X -> B:

⟨f, g⟩: X -> A × B

where

π₁ ∘ ⟨f, g⟩ = f
π₂ ∘ ⟨f, g⟩ = g

Product of Morphisms:

For morphisms f: A -> A' and g: B -> B':

f × g: A × B -> A' × B'
f × g = ⟨f ∘ π₁, g ∘ π₂⟩

Coproduct Morphisms #

Case Analysis Morphism:

For morphisms f: A -> X and g: B -> X:

[f, g]: A + B -> X where

[f, g] ∘ ι₁ = f
[f, g] ∘ ι₂ = g

Coproduct of Morphisms:

For morphisms f: A -> A' and g: B -> B':

f + g: A + B -> A' + B'
f + g = [ι₁ ∘ f, ι₂ ∘ g]

where ι₁ and ι₂ denote the canonical injections into the target coproduct A' + B'.

Exponential Morphisms #

Currying Morphism:

For morphism f: X × A -> B:

curry(f): X -> B^A

where eval ∘ (curry(f) × id_A) = f

Function Composition:

For morphisms f: A -> B and g: B -> C:

g^A: B^A -> C^A (post-composition with g)
g^A = curry(g ∘ eval)

Function Precomposition:

For morphisms f: A' -> A and object B:

(-)^f: B^A -> B^A' (pre-composition with f)
(-)^f = curry(eval ∘ (id_{B^A} × f))

Laws and Equations #

Product Laws #

Projection Laws:

π₁ ∘ ⟨f, g⟩ = f
π₂ ∘ ⟨f, g⟩ = g

Eta Law (Surjective Pairing):

⟨π₁, π₂⟩ = id_{A × B}

Fusion Law:

⟨f, g⟩ ∘ h = ⟨f ∘ h, g ∘ h⟩

Coproduct Laws #

Injection Laws:

[f, g] ∘ ι₁ = f
[f, g] ∘ ι₂ = g

Eta Law (Injective Case Analysis):

[ι₁, ι₂] = id_{A + B}

Fusion Law:

h ∘ [f, g] = [h ∘ f, h ∘ g]

Exponential Laws #

Evaluation Law:

eval ∘ (curry(f) × id_A) = f

Eta Law (Function Extensionality):

curry(eval) = id_{B^A}

Beta Law (Currying/Uncurrying):

curry(f) = λx.λy.f(x,y) (in lambda notation)
uncurry(curry(f)) = f
curry(uncurry(g)) = g

Curry Fusion:

curry(f ∘ (g × id_A)) = curry(f) ∘ g

Hom-set Characterization #

Product Hom-set Isomorphism

Hom(X, A × B) ≅ Hom(X, A) × Hom(X, B)

Functions into a product correspond to pairs of functions into the components.
Coproduct Hom-set Isomorphism

Hom(A + B, X) ≅ Hom(A, X) × Hom(B, X)

Functions out of a coproduct correspond to pairs of functions from the components.
Exponential Hom-set Isomorphism

Hom(X × A, B) ≅ Hom(X, B^A)

Functions from a product correspond to curried functions.

The Necessity of Combining Objects #

In everyday programming we constantly need to combine different types of data:

// Combining different pieces of information
interface User {
  name: string;
  age: number;
  email: string;
}

// Representing alternatives
type PaymentMethod = 'credit' | 'debit' | 'cash' | 'digital';

type SuccessResult = { numberOdRecords : number }

type ErrorResult = { error: Error }

// Database query results
type QueryResult = SuccessResult | ErrorResult;

Three Fundamental Ways to Combine Objects #

In cartesian closed categories with finite coproducts, there are three fundamental universal constructions used to combine objects:

Products AND combinations

Products represent both pieces of information simultaneously:
- Pairs, tuples, records, structs
- Cartesian products in mathematics ^[4]
- All fields must be present
Coproducts OR combinations

Coproducts represent one of several alternatives:
- Union types, sum types, tagged unions
- Disjoint unions in mathematics
- Exactly one alternative is present
Exponentials FUNCTION combinations

Exponentials represent functions from one type to another:
- Function types, closures, lambdas
- Function spaces in mathematics
- Computation and transformation

Visualizing product, coproduct and exponential #

1. The product A x B with its projections π₁ and π₂:

Product combines objects - you get BOTH A AND B

                  A × B
                 /     \
            π₁  /       \  π₂
               /         \
              v           v
             A             B

From any X with morphisms to both A and B,
there's a unique "pairing" morphism ⟨f,g⟩ to the product:

             f
       X ---------> A
       |           ↗
       |          /
⟨f,g⟩  |         / π₁
       |        /
       v       /
      A × B ---
       |
       | π₂
       v
       B <------- X
            g

The diagram commutes:
• π₁ ∘ ⟨f,g⟩ = f  (extract first component)
• π₂ ∘ ⟨f,g⟩ = g  (extract second component)


2. The coproduct A + B with its injections ι₁ and ι₂:

Coproduct represents choice - you get EITHER A OR B

        A             B
         \           /
      ι₁  \         /  ι₂
           \       /
            v     v
            A + B

From the coproduct to any X with morphisms from both A and B,
there's a unique "case analysis" morphism [f,g]:

      A --------> X <------- B
       \         ↗        ↙
        \       /        /
      ι₁ \     /f      /g
          \   /       /
           v /       / ι₂
          A + B ----
               [f,g]
                |
                v
                X

The diagram commutes:
• [f,g] ∘ ι₁ = f  (handle A case)
• [f,g] ∘ ι₂ = g  (handle B case)


3. Products and coproducts are categorical duals - same structure with arrows reversed:

PRODUCT (Multiple inputs -> Single output):

    A <---- A × B ----> B
            (contains both A and B)

COPRODUCT (Single input ← Multiple outputs):

    A ----> A + B <---- B
            (contains either A or B)

The universal properties are dual:
• Product:   Functions INTO product ≅ Pairs of functions into components
• Coproduct: Functions FROM coproduct ≅ Pairs of functions from components


4. The exponential B^A with its evaluation morphism:

Exponential represents functions - transformations from A to B

        B^A × A ---------> B
         ^               ↗
         |         eval /
curry(f) |             /
         |            /
         |           /
       X × A -------/
            f

From any X with a morphism f: X x A -> B,
there's a unique "currying" morphism curry(f): X -> B^A:

The diagram commutes:
• eval ∘ (curry(f) x id_A) = f  (function application)

This captures lambda abstraction:
- B^A represents "functions from A to B"
- curry(f) abstracts over the A parameter
- eval applies functions to arguments


5. The three constructions together form a complete system:

LOGICAL INTERPRETATION:
• Product A x B    ≅  A ∧ B    (AND - conjunction)
• Coproduct A + B  ≅  A ∨ B    (OR - disjunction)
• Exponential B^A  ≅  A -> B    (IMPLIES - implication)

PROGRAMMING INTERPRETATION:
• Product:    Records, tuples, structs
• Coproduct:  Union types, enums, sum types
• Exponential: Function types, lambdas, closures

Examples #

Product examples #

TypeScript: { name: string, age: number }
Haskell:    (String, Int)
C#:         record Person(string Name, int Age);

Structure: name AND age (both present)

     PersonRecord
      /         \
   name         age
  (String)     (Int)

Coproduct examples #

TypeScript: string | number
Haskell:    Either String Int
C#:         abstract record StringOrNumber;
            record Str(string Value) : StringOrNumber;
            record Num(int Value) : StringOrNumber;

Structure: string OR number (one present)

    String
      \
       \
        v
   StringOrNumber
        ^
       /
      /
   Number

Pattern matching handles each case:
match value {
  String(s) => handleString(s),
  Number(n) => handleNumber(n)
}

Exponential examples #

TypeScript: (x: A) => B
Haskell:    A -> B
JavaScript: function(a) { return b; }

Structure: functions FROM A TO B (transformation)

    A ----function----> B

Function Space B^A:
- Contains all possible functions A -> B
- Supports composition, currying
- Enables higher-order programming

const add: (x: number) => (y: number) => number =
  x => y => x + y;

const multiply: (x: number) => (y: number) => number =
  x => y => x * y;

Without products and coproducts, we'd face fundamental limitations:

The Pairing Problem #

-- How do we create a function that takes two inputs?
-- Without products, we can't express: f: A, B -> C
-- We need: f: A x B -> C

processUserData :: String -> Int -> String -> UserProfile
-- This is really: (String, Int, String) -> UserProfile

The Choice Problem #

// How do we handle different possible outcomes?
function parseNumber(input: string): number | "error" {
  // Without coproducts, we'd need ugly workarounds
  // With coproducts: Result<number, string>
}

The Composition Problem #

-- How do we compose functions with multiple inputs/outputs?
f :: A -> B x C  -- Returns a product
g :: B -> D
h :: C -> E

-- We need systematic ways to work with these combinations

The Abstraction Problem #

-- How do we abstract over parameters systematically?
-- Without exponentials, we can't express higher-order functions

-- With exponentials, we get currying and partial application:
add :: Int -> Int -> Int  -- Really: Int -> (Int -> Int)
add x y = x + y

addFive :: Int -> Int     -- Partial application
addFive = add 5           -- curry(add)(5)

map :: (a -> b) -> [a] -> [b]  -- Higher-order function
filter :: (a -> Bool) -> [a] -> [a]

Real World Applications #

Products and coproducts appear everywhere in real-world programming, often without us explicitly recognizing them as categorical constructions. Understanding them categorically helps us write more robust, composable code.

Database Design with Products #

Database tables naturally represent products - each row contains multiple pieces of related information:

-- User table represents a product of multiple fields
CREATE TABLE users (
    id INTEGER,           -- Component 1
    name VARCHAR(100),    -- Component 2
    email VARCHAR(255),   -- Component 3
    created_at TIMESTAMP  -- Component 4
);

-- The projection morphisms are column selections
SELECT name FROM users;     -- π₁: User -> String
SELECT email FROM users;    -- π₂: User -> String
SELECT created_at FROM users; -- π₃: User -> Timestamp

-- JOIN operations create larger products
SELECT u.name, u.email, p.title, p.content
FROM users u
JOIN posts p ON u.id = p.author_id;
-- Result: Product of User fields × Post fields

API Response Handling with Coproducts #

HTTP APIs naturally return coproducts - either success data or error information:

type User = {
    firstName: string;
    lastName: string;
}

// API responses are coproducts - either success OR error
type ApiResponse<T> =
  | { success: true; data: T }
  | { success: false; error: string; code: number };

// Case analysis handles both possibilities
function handleUserResponse(response: ApiResponse<User>): string {
  if (response.success) {
    return `Welcome, ${response.data.firstName}!`;  // Handle success case
  } else {
    return `Error ${response.code}: ${response.error}`; // Handle error case
  }
}

// Network requests naturally produce coproducts
async function fetchUser(id: number): Promise<User | Error> {
  try {
    const response = await fetch(`/api/users/${id}`);
    return await response.json(); // Success case
  } catch (error) {
    return new Error(`Failed to fetch user: ${error}`); // Error case
  }
}

Configuration Systems with Products #

Application configurations are products combining multiple settings:

// Configuration is a product of multiple components
interface DatabaseConfig {
  host: string;
  port: number;
  database: string;
  credentials: { username: string; password: string };
}

interface ServerConfig {
  port: number;
  env: 'development' | 'staging' | 'production';
  logging: { level: string; format: string };
}

interface FeatureFlags {
    flag1: boolean;
    flag2: boolean;
    flag3: boolean;
}

// Application config is a product of sub-configurations
interface AppConfig {
  database: DatabaseConfig;  // Component 1
  server: ServerConfig;      // Component 2
  features: FeatureFlags;    // Component 3
}

// Projection functions extract specific configuration parts
const getDatabaseUrl = (config: AppConfig): string =>
  `${config.database.host}:${config.database.port}/${config.database.database}`;

const getLogLevel = (config: AppConfig): string =>
  config.server.logging.level;

State Management with Coproducts #

Application states often represent mutually exclusive conditions:

// Loading states are coproducts - exactly one state at a time
type LoadingState<T> =
  | { type: 'idle' }
  | { type: 'loading'; progress?: number }
  | { type: 'success'; data: T }
  | { type: 'error'; message: string; retryCount: number };

// React component handles all cases
function UserProfile({ userId }: { userId: string }) {
  const [state, setState] = useState<LoadingState<User>>({ type: 'idle' });

  const renderContent = () => {
    switch (state.type) {  // Case analysis
      case 'idle':
        return <button onClick={loadUser}>Load User</button>;
      case 'loading':
        return <Spinner progress={state.progress} />;
      case 'success':
        return <UserCard user={state.data} />;
      case 'error':
        return <ErrorMessage message={state.message} onRetry={loadUser} />;
    }
  };

  return <div>{renderContent()}</div>;
}

Form Validation with Products and Coproducts #

Form validation combines products (collecting all field values) with coproducts (success or failure):

// Form data is a product of field values
interface RegistrationForm {
  email: string;        // Component 1
  password: string;     // Component 2
  confirmPassword: string; // Component 3
  acceptTerms: boolean; // Component 4
}

// Validation result is a coproduct
type ValidationResult<T> =
  | { valid: true; data: T }
  | { valid: false; errors: string[] };

// Validation combines projections with case analysis
function validateRegistration(form: RegistrationForm): ValidationResult<User> {
  const errors: string[] = [];

  // Projections extract individual fields for validation
  if (!isValidEmail(form.email)) {
    errors.push('Invalid email format');
  }

  if (form.password.length < 8) {
    errors.push('Password must be at least 8 characters');
  }

  if (form.password !== form.confirmPassword) {
    errors.push('Passwords do not match');
  }

  if (!form.acceptTerms) {
    errors.push('You must accept the terms');
  }

  // Return coproduct result
  if (errors.length === 0) {
    return {
      valid: true,
      data: { email: form.email, hashedPassword: hash(form.password) }
    };
  } else {
    return { valid: false, errors };
  }
}

Message Passing Systems #

Message-based systems use coproducts to represent different message types:

// Message types form a coproduct - exactly one message type
type Message =
  | { type: 'user_registered'; userId: string; email: string }
  | { type: 'order_created'; orderId: string; amount: number; items: Item[] }
  | { type: 'payment_processed'; orderId: string; transactionId: string }
  | { type: 'notification_sent'; userId: string; channel: string };

// Message handlers use case analysis
class MessageProcessor {
  async handleMessage(message: Message): Promise<void> {
    switch (message.type) {
      case 'user_registered':
        await this.sendWelcomeEmail(message.email);
        await this.createUserProfile(message.userId);
        break;

      case 'order_created':
        await this.validateInventory(message.items);
        await this.processPayment(message.orderId, message.amount);
        break;

      case 'payment_processed':
        await this.fulfillOrder(message.orderId);
        await this.sendConfirmation(message.transactionId);
        break;

      case 'notification_sent':
        await this.logDelivery(message.userId, message.channel);
        break;
    }
  }
}

Functional Programming Patterns #

Functional languages make the categorical nature explicit:

import Control.Monad ((>=>))

type UserProfile = (String, Int, String)  -- (name, age, email)

data DatabaseConfig = DatabaseConfig
  { host :: String
  , port :: Int
  , database :: String
  }

data User = User
  { name :: String
  , age :: Int
  , email :: String
  } deriving (Eq, Show)

data DatabaseError where
  DatabaseError :: String -> DatabaseError
  deriving (Eq, Show)

-- Coproducts as sum types
data Result a b = Success a | Error b
data ParseResult = ParsedNumber Int | ParsedString String | ParseError String

-- Exponentials as function types
type Validator a = a -> Either String a
type Transform a b = a -> b
type Predicate a = a -> Bool

-- Higher-order functions work naturally with products/coproducts/exponentials
processResults :: [Result User DatabaseError] -> IO ()
processResults results = do
  let (users, errors) = partitionResults results
  mapM_ saveUser users
  mapM_ logError errors

partitionResults :: [Result a b] -> ([a], [b])
partitionResults = foldr separate ([], [])
  where
    separate (Success a) (as, bs) = (a:as, bs)
    separate (Error b) (as, bs) = (as, b:bs)

-- Currying and partial application with exponentials
validateAndSave :: Validator User -> [User] -> IO [Result User String]
validateAndSave validator = mapM (validate >=> save)
  where
    validate user = case validator user of
      Left err -> return (Error err)
      Right validUser -> return (Success validUser)

    save (Error e) = return (Error e)
    save (Success u) = do
      saveUser u
      return (Success u)

saveUser :: User -> IO ()
saveUser u = putStrLn ("Saved user: " ++ show u)

logError :: DatabaseError -> IO ()
logError (DatabaseError msg) = putStrLn ("DB error: " ++ msg)

Higher-Order Functions and Callbacks #

Exponential objects naturally model callback patterns and higher-order functions:

// Event handlers are exponential objects - functions from events to actions
type EventHandler<T> = (event: T) => void;

// Higher-order functions use exponentials
function debounce<T extends any[]>(
  fn: (...args: T) => void,  // Exponential: function type
  delay: number
): (...args: T) => void {   // Returns exponential
  let timeoutId: number;

  return (...args) => {     // Lambda/closure - exponential object
    clearTimeout(timeoutId);
    timeoutId = setTimeout(() => fn(...args), delay);
  };
}

// Array methods showcase exponential objects everywhere
const numbers = [1, 2, 3, 4, 5];

const doubled = numbers.map(x => x * 2);        // (number) => number
const evens = numbers.filter(x => x % 2 === 0); // (number) => boolean
const sum = numbers.reduce((acc, x) => acc + x, 0); // (number, number) => number

type User = { active: boolean }

function render(_: User[]):void {}

// Promises chain using exponential objects
fetch('/api/users')
  .then(response => response.json())     // (Response) => Promise<any>
  .then((users: User[]) => users.filter(u => u.active)) // (User[]) => User[]
  .then(activeUsers => render(activeUsers))    // (User[]) => void
  .catch(error => console.error(error));       // (Error) => void

Configuration and Dependency Injection #

Exponential objects enable flexible configuration through function injection:

// Configuration using exponential objects (function injection)
interface Logger {
  log: (message: string) => void;        // Exponential
  error: (error: Error) => void;         // Exponential
}

interface DatabaseClient {
  query: <T>(sql: string) => Promise<T>; // Exponential
  transaction: <T>(fn: (client: DatabaseClient) => Promise<T>) => Promise<T>; // Higher-order
}

type User = { id : string }

type UserData = User

type ValidationResult<T> = {
    user?: T;
    valid: boolean;
}

// Result is a coproduct capturing success or error
type Result<T, E> =
  | { success: true; data: T }
  | { success: false; error: E };

// Minimal app configuration for dependency injection
interface DbConfig {
  connectionString: string;
}

interface LoggingConfig {
  level: 'debug' | 'info' | 'warn' | 'error';
}

interface ValidationConfig {
  // Example rule: require non-empty id
  requireNonEmptyId: boolean;
}

interface AppConfig {
  db: DbConfig;
  logging: LoggingConfig;
  validation: ValidationConfig;
}

// Dependency injection using exponentials
class UserService {
  constructor(
    private db: DatabaseClient,
    private logger: Logger,
    private validator: (user: User) => ValidationResult<User> // Exponential injection
  ) {}

  async createUser(userData: UserData): Promise<Result<User, Error>> {
    try {
      // Use injected exponential (validator function)
      const validation = this.validator(userData);

      if (!validation.valid) {
        return { success: false, error: new Error('Validation failed') };
      }

      // Use injected database exponentials
      const user = await this.db.query<User>(
        'INSERT INTO users ... RETURNING *'
      );

      // Use injected logger exponential
      this.logger.log(`User created: ${user.id}`);

      return { success: true, data: user };
    } catch (error) {
      this.logger.error(error as Error);
      return { success: false, error: error as Error };
    }
  }
}

// Factory function returns configured service (exponential)
const createUserService = (config: AppConfig): UserService =>
  new UserService(
    createDatabaseClient(config.db),
    createLogger(config.logging),
    createUserValidator(config.validation)
  );

// Implementations for dependencies used by the factory
const createDatabaseClient = (_: DbConfig): DatabaseClient => {
  return {} as unknown as DatabaseClient;
};

const createLogger = (_: LoggingConfig): Logger => {
  return {} as unknown as Logger;
};

const createUserValidator = (_: ValidationConfig) =>
  (user: User): ValidationResult<User> => {
    return { valid: true, user };
  };

Symmetry #

When we study products, coproducts, and exponentials together, we notice the symmetry that emerges by connecting logic, computation, and abstract algebra. The symmetry manifests at multiple levels - from the purely structural (arrow reversal) to the deeply conceptual (logic-programming correspondence). Understanding these symmetries helps us see why category theory provides such a unified framework for mathematics and computer science.

Duality Symmetry #

(Products - Coproducts)

Products and coproducts are categorical duals - they have exactly the same structure but with all arrows reversed:

PRODUCT PATTERN:
Multiple objects -> Single combined object
    A <---- A × B ----> B
     π₁               π₂
(projections extract components)

COPRODUCT PATTERN:
Single combined object ← Multiple objects
    A ----> A + B <---- B
     ι₁               ι₂
(injections insert components)

This means every theorem about products automatically gives you a theorem about coproducts by reversing arrows!

Logical Symmetry #

(Curry-Howard Correspondence) ^[6]

The three constructions correspond perfectly to logical operators:

CATEGORY THEORY	LOGIC	PROGRAMMING
Product `A × B`	`A ∧ B` (AND)	Records/Tuples
Coproduct `A + B`	`A ∨ B` (OR)	Union Types
Exponential `B^A`	`A -> B` (IMPL)	Function Types

This symmetry reveals that programming is logic and logic is category theory!

Hom-Set Symmetry #

The universal properties create isomorphisms:

Hom(X, A × B) ≅ Hom(X, A) × Hom(X, B) [Product]
Hom(A + B, X) ≅ Hom(A, X) × Hom(B, X) [Coproduct]
Hom(X × A, B) ≅ Hom(X, B^A) [Exponential]

Notice the symmetric placement of the constructions in these isomorphisms!

Algebraic Symmetry #

They satisfy symmetric laws:

PRODUCTS	COPRODUCTS	EXPONENTIALS
`π₁ ∘ ⟨f,g⟩ = f`	`[f,g] ∘ ι₁ = f`	`eval ∘ (curry(f) × id_A) = f`
`π₂ ∘ ⟨f,g⟩ = g`	`[f,g] ∘ ι₂ = g`	`curry(eval) = id`
`⟨π₁,π₂⟩ = id`	`[ι₁,ι₂] = id`	`curry(f)` uniquely exists

Practical Symmetry in Programming #

In code, this symmetry appears as:

// CONSTRUCTING (putting data together)
const product: [A, B] = [a, b];           // Product construction
const coproduct: A | B = a;               // Coproduct construction
const exponential: (a: A) => B = a => b;  // Exponential construction

// DESTRUCTURING (taking data apart)
const [a, b] = product;                   // Product destruction
const result = match coproduct {...};     // Coproduct destruction
const result = exponential(a);            // Exponential destruction

Three simple patterns:

Generate all of modern type theory

Underlie all functional programming languages

Connect logic, computation, and mathematics

Show that seemingly different concepts (AND/OR/IMPLIES, tuples/unions/functions, products/coproducts/exponentials) are all the same mathematical structure viewed from different angles

Insight:

What appears as three different concepts (products, coproducts, exponentials) are actually facets of a single, unified mathematical reality.

Conclusion #

What makes products, coproducts, and exponentials special is that they're universal constructions - they're not just convenient ways to combine objects, but the unique best way to do so. This "best" property is captured by universal properties that characterize these constructions through their relationships with morphisms.

Together, these three constructions provide

✅ Type Safety: Products, coproducts, and exponentials help us model data and computation precisely, catching errors at compile time rather than runtime.
✅ Composability: Understanding these patterns helps us build more composable systems where components fit together naturally.
✅ Error Handling: Coproducts provide principled ways to handle errors without exceptions or null values.
✅ State Modeling: Complex application states are often best modeled as combinations of products (data) and coproducts (exclusive states).
✅ API Design: REST APIs, GraphQL schemas, and message protocols naturally use these patterns for robust communication.
✅ Functional Programming: Exponentials enable higher-order functions, currying, and powerful abstraction mechanisms.

Understanding products, coproducts, and exponentials categorically helps us recognize these patterns across different domains and implement them more systematically. They form the categorical foundation for modern type systems and functional programming languages.

Source code #

Reference implementation (opens in a new tab)

References

Product (opens in a new tab) · Back
Projection (opens in a new tab) · Back
Coproduct (opens in a new tab) · Back
Cartesian product (opens in a new tab) · Back
Exponential object (opens in a new tab) · Back
Curry–Howard correspondence (opens in a new tab) · Back