Arun Pandian M

Arun Pandian M

Android Dev | Full-Stack & AI Learner

Coproducts — Modeling “Either This or That” in Code

Most bugs don’t come from what your program does. They come from what your program **assumes cannot happen**.

You think a value will always be present. You assume a request will always succeed. You believe a state will always be valid.

Reality disagrees. A user can be unauthenticated. An API can fail. A screen can be loading.

So the real question is:

That’s where Coproducts come in.

The Core Idea

A coproduct represents a choice:

A + B

Meaning:

A value is either **A OR B** 

Programming Intuition

In Kotlin:

sealed class Result<out T> {
    data class Success<T>(val value: T) : Result<T>()
    data class Error(val message: String) : Result<Nothing>()
}

This means:

Result = Success + Error

At runtime, it’s exactly one of them

Why Not Just Use Null?

val user: User? = null

This tells you that a value is missing, but it does not explain the reason behind it.

Coproducts fix this:

Result.Error("User not found")

Now your system knows what happened

Category Theory View

A coproduct of A and B is an object C with two injections:

i : A → C  
j : B → C

Meaning

  • You can put A into C
  • You can put B into C
  • The Universal Property (Important Insight)

    If you know how to handle:`

    A → X  
    B → X

    Then you automatically know how to handle:

    (A + B) → X
    

    Kotlin Equivalent (Factorizer)

    fun <A, B, C> fold(
        left: (A) -> C,
        right: (B) -> C
    ): (Result<A,B>) -> C = { result ->
        when (result) {
            is Result.Success -> left(result.value)
            is Result.Error -> right(result.error)
        }
    }
    
    sealed class Result<out A,out B> {
     data class Success<A>(val value: A) : Result<A, Nothing>()
        data class Error<B>(val error: B) : Result<Nothing,B>()
    }

    This is the coproduct factorizer

    https://storage.googleapis.com/lambdabricks-cd393.firebasestorage.app/coproduct_factorizer.svg?X-Goog-Algorithm=GOOG4-RSA-SHA256&X-Goog-Credential=firebase-adminsdk-fbsvc%40lambdabricks-cd393.iam.gserviceaccount.com%2F20260521%2Fauto%2Fstorage%2Fgoog4_request&X-Goog-Date=20260521T005023Z&X-Goog-Expires=3600&X-Goog-SignedHeaders=host&X-Goog-Signature=07a14d8ba7f086ea2ee9eb54599dd81e9bcbd6242234cf1178828301fcb2c2125277af485ede5ae3848801ccbf8b26d47cbcc3b93ab26460eb225bd8120971109760a988d64856b29eddc8d1a60701c02bcc6738fb2cb9fb8565987f2c63e5f40661e40cc72c09a50d7d2a633ab7ec8ddf82b4bfa22c8fb9d69bc790c8791c1f7a4375649119a7595cecae3d81e28f904dc1c1bc665b4223f64841cbedf04e42f6f6d303539dcb5256e984ce719516743c129805eb22d5c460c2b1dea7a28bb5cbde2384320d8695eb07fcc55d4ebe86f44c2d59a9c8cc661ce5a31d7eeaadc39de8482a5f201223e6ba861ed1f6e31158ff5ad6a19192d91a281c96f7a9599d

    Real-World Use Case (Android)

    UI State

    When building apps, we often represent UI like this:

    sealed class UiState {
        object Loading : UiState()
        data class Success(val data: String) : UiState()
        data class Error(val message: String) : UiState()
    }

    Why this matters

    A common (but problematic) way to model UI state is:

    var loading = false
    var data: String? = null
    var error: String? = null

    At first glance, this looks simple.

    But it introduces a serious issue:

    • loading = true and data != null can exist together

    • error != null and data != null can exist together

    These are invalid combinations, but nothing prevents them.

    What coproduct gives us

    With: UiState

    You are saying:

    At any moment, the UI is in exactly one state.

    • Loading

    • Success

    • Error

    No invalid combinations are possible.

    This is the essence of a coproduct:

    A value can be one of many possibilities, but only one at a time.

    Composition (Short-Circuiting)

    Coproducts are not just about modeling — they also improve how we write logic.

    Consider this pipeline:

    validate(id) .flatMap(::fetchUser) .flatMap(::mapUi)

    What happens here?

    • If validate fails → everything stops

    • If fetchUser fails → next step is skipped

    • If all succeed → final result is produced

    You don’t write manual checks like:

    if (error != null) return error

    The structure itself ensures:

    Once an error happens, the rest of the pipeline does not run.

    Why this is powerful

    • No nested if conditions

    • No scattered error handling

    • Clear flow of data

    The system enforces correctness for you.

    Final takeaway

    • Product → combine values

    • Coproduct → choose one possibility

    Coproducts let you model real-world situations where something can be in one state at a time — and they ensure your code stays correct by design.
    #functionalprogramming#kotlinfp#algebraicdatatypes#composablesystems#mathfordevelopers#softwaredesign#coproduct#buildinpublic#typetheory#eithertype#errorhandling#fpconcepts#learninpublic#datamodeling#categorytheory