Context based programming

[Pragrammist]

---

What a problem.

A lot of languages have context.
Different programming scopes (gaming, OS, backend, frontend, desktop apps, database operations, etc.) have the same fundamental concept: context. I do not mean something abstract; I mean different data in different contexts and different restrictions and capabilities.

---

Games (ECS):

Entity = id
Components = Position, Velocity, Health
System = function that works with components

Components are data in some context; a system is a function that demands that data/context.
The whole game is a container of contexts.

But the language does not know about it; it is on the developer’s shoulders.

---

UI (React / Svelte / Solid)

const theme = useContext(ThemeContext)
const user = useContext(UserContext)

Svelte:

export const store = writable(...)

You have global and local state context, but context is outside the language.
Dependencies are not explicit, not in function signatures, and the type system does not see them.
You have context, but it is not built into the language.

---

pub fn handle(req, env) {
  env.logger.info(...)
  env.db.query(...)
}

fn handler(req: Request, ctx: AppContext) { ... }

You need to pass env through all functions, even those that do not need it.
You also get something like a God object that contains all context.

Functions do not have minimal demands. I mean it is not explicit.
A function may need only two variables from the context, but you pass the entire context.
Yes, you can pass only those two variables, but it is painful every time to create new arguments with context for each function.

In OOP languages like TypeScript, C#, Java you have DI, but it is hard to scale.
It is a myth that they are good for large-scale codebases.

Operating systems also have their own contexts, but for simplicity I do not want to talk about that.

I hope you now understand that context is fundamental, but no languages have syntax for this.

Your code, your app, your 10-million+ LOC codebase are just different contexts that replace each other in the flow.

---

What problem I want to solve:

You want to write pure functions and you want to control side effects, but you need to pass different contexts.

In practice, you need to pass your environment all over the code.

Reader / IO-like abstractions.
Not explicitly global dependencies like AppContext, when a function does not need all fields from it, but you still pass it.

I suggest treating context as a different language abstraction.

Context is a structural environment of data and capabilities that a function can use, but not only as an argument.

---

Creating context

context AccountContext {
  account: Account
  config: Config
  row: Int // you read account from Google Sheets in this example
}

fn update_id() with AccountContext {
  // account, config, and row are available directly
  let new_id = generate_id(config)
  save_to_database(account, new_id, row)
}

You can use config explicitly.

---

fn process(account: Account, config: Config, row: Int) {
  let ctx = context AccountContext {
    account: account
    config: config
    row: row
  }

  update_id()
}

This is how you initialize context.
ctx is just a lexical scope; it is not state.
update_id automatically uses its variables.

Context is not global state.
You create it explicitly.
It has lexical visibility.
It is local to functions.
It has value semantics, not objects.

---

context AccountOnly {
  account: Account
}



context AccountContext with AccountOnly {
  config: Config
  row: Int // you read account from Google Sheets in this example
}


fn print_account() with AccountOnly {
  io.println(account.name)
}


fn process(account: Account, config: Config, row: Int) {
  let full_ctx = context AccountContext {
    account: account
    config: config
    row: row
  }

  print_account()
}

As you can see, you narrow the context and take only what you need.

---

context ExtendedContext {
  account: Account
  config: Config
  row: Int
  logger: Logger
}

fn process(account, config, row, logger) {
  let base_ctx = context AccountContext {
    account: account
    config: config
    row: row
  }

  let extended_ctx = context ExtendedContext {
      logger: logger
  }

  do_something() // needs ExtendedContext
}

fn do_something() with ExtendedContext {
}

You can also expand context if you need it.

---

context AccountContext with AccountOnlyContext {
  config: Config
  row: Int // you read account from Google Sheets in this example
}

context AccountOnlyContext {
  account: Account
}

fn main() {
  let _ = context AccountContext {
    account: account
    config: config
    row: row
  }

  do_something_1()
}

fn do_something_1() with AccountContext {
  // compiler passes context for you
  do_something_2()
}

fn do_something_2() with AccountContext {
  // AccountOnlyContext is part of AccountContext
  do_something_3()
}

fn do_something_3() with AccountOnlyContext {}

As you can see, if you initialize context once or a subcontext, you do not need to pass and initialize it again, and you can use it across the app.

If needed, you can reinitialize context if you have new data.

Contexts are explicit.
Contexts have lexical scope.
Contexts are not global.
Contexts are not mutable; you need to reinitialize context if data changes.

Whether you can call a function or not is decided at compile time.

This is an attempt to take this idea from OOP languages—context—but without objects, mutations, and implicit dependencies.

---

fn do_something_2(ctx: AccountContext): AccountDatabaseContext with EnvContext {
}

You can also use context as a value.

Syntax is not final; I am just showing ideas:
you can create context, expand and narrow it, create one context from multiple contexts,
functions can require multiple contexts,
you can treat context syntactically like an object, but it is not an object in the sense that it has no state.

With context, you can also expand behavior infinitely.
You have some domain object/behavior, and with context you can add data needed for infrastructure code—for example, databases or Google Sheets.

---

// ==============================
// DOMAIN (PURE, NO INFRASTRUCTURE)
// ==============================

type Account {
  Account(
    service: String,
    game: String,
    platform: String,
    title: String,
    description: String,
    price: String,
    status: String,
    id: String
  )
}

// Pure domain logic.
// No context. No sheets. No IO.
// This function can be tested in isolation.
fn is_ready_for_posting(account: Account) -> Bool {
  account.status == "posted" && account.id == ""
}


// ==============================
// INFRASTRUCTURE DATA (SHEETS)
// ==============================

type TableMeta {
  TableMeta(
    spreadsheet_id: String,
    sheet_name: String,
    sheet_index: Int,
    row_number: Int,
    skipped_rows: Int
  )
}


// ==============================
// CONTEXTS (EXPLICIT AND MINIMAL)
// ==============================

// Context that binds a domain Account to its table metadata.
context AccountRowContext {
  account: Account
  table_meta: TableMeta
}

// Global Sheets capability.
// Created once for the whole application.
context SheetsContext {
  sheets: SheetsClient
}


// ==============================
// APPLICATION ENTRY POINT
// ==============================

fn main() {
  // Initialize Google Sheets client ONCE
  let sheets_ctx = context SheetsContext {
    sheets: connect_to_google_sheets()
  }

  // Read all tables and build account contexts
  let account_rows = load_all_accounts()

  // Process every account together with its table metadata
  account_rows
  |> list.each(fn(row_ctx) {
       process_account()
     })
}


// ==============================
// LOADING DATA FROM SHEETS
// ==============================

// Reads all sheets once and produces a list of AccountRowContext
fn load_all_accounts()
  with SheetsContext
  -> List(AccountRowContext)
{
  let spreadsheet_id = "spreadsheet-id"

  sheets.read_all_tables(spreadsheet_id)
  |> list.flat_map(fn(table) {
       read_table_accounts(spreadsheet_id, table)
     })
}

// Reads a single sheet and binds each Account to its row metadata
fn read_table_accounts(
  spreadsheet_id: String,
  table: SheetTable
)
  with SheetsContext
  -> List(AccountRowContext)
{
  table.rows
  |> list.indexed
  |> list.filter_map(fn(index, row) {

       // Parse domain object from raw row data
       case parse_account(row) {
         Ok(account) ->

           // Build metadata that should NOT live in the domain
           let meta = TableMeta(
             spreadsheet_id: spreadsheet_id,
             sheet_name: table.name,
             sheet_index: table.index,
             row_number: index + 1,
             skipped_rows: table.skipped_rows
           )

           // Explicitly bind Account + metadata via context
           let ctx = context AccountRowContext {
             account: account
             table_meta: meta
           }

           Some(ctx)

         Error(_) ->
           None
       }
     })
}


// ==============================
// APPLICATION LOGIC
// ==============================

// Orchestration logic.
// Has access to Account + row metadata + Sheets capability.
fn process_account()
  with AccountRowContext, SheetsContext
{
  // Domain rule stays pure and explicit
  if is_ready_for_posting(account) {

    // External side-effect (API call)
    let new_id = create_offer(account)

    // Infrastructure write-back requires Sheets + row metadata
    update_account_id(new_id)
  }
}


// ==============================
// SHEETS SIDE-EFFECTS
// ==============================

// Updates a single cell in Google Sheets.
// Requires ONLY what it actually needs.
fn update_account_id(new_id: String)
  with AccountRowContext, SheetsContext
{
  sheets.update_cell(
    table_meta.spreadsheet_id,
    table_meta.sheet_name,
    table_meta.row_number,
    "ID_COLUMN",
    new_id
  )
}

---

In the examples, syntax may be inconsistent, but the main point is the idea of context.

With these ideas, Gleam is not an FP language, but a context-oriented one.
It brings together OOP and FP, but takes the best from both worlds.

---

Principles

1. Context as the Primary Abstraction

Context is the primary unit of program organization.

Programs are structured around contexts rather than classes or modules.
A context represents a structured environment of data and capabilities in which functions operate.

2. Requirements Instead of Dependencies

Functions declare requirements on their environment rather than accepting dependencies explicitly.
A function specifies what it needs, not how it is passed.

3. Automatic Lexical Binding

Contexts are bound automatically through lexical scope.

If a required context is available in the current lexical environment, it is used without explicit passing.

4. Structural Compatibility

Compatibility is determined structurally, not nominally.

A function can operate in any context that structurally satisfies its requirements, regardless of the context’s name or origin.

5. Minimal Context Principle

A function observes only the minimal subset of the environment it requires.

The effective context is automatically narrowed to the required structure.

6. Context Composition

Complex environments are built by composing simpler contexts.

Composition is preferred over nesting and inheritance.

7. Local Extensibility of the Environment

A context can be locally extended without modifying existing code.

New data and capabilities are introduced by constructing extended contexts rather than mutating existing structures.

8. Context as a Value

A context may be used both implicitly as an environment and explicitly as a value.

Contexts may be:

• passed,
• returned,
• stored,
• combined.

Both forms are equivalent and interoperable.

9. Explicit Effects

All side effects must be expressed through context.

Effects are not implicit; they are enabled only through explicitly required capabilities.

10. No Hidden Mutation of Context

Contexts do not allow implicit or hidden mutation.

Changes to the environment are expressed by constructing new contexts rather than mutating existing ones.

This gives contexts value semantics rather than object-internal state.

11. Flat Accessibility

Context properties are accessed directly, without navigational indirection.

A context provides locality similar to this, but without object mutation or encapsulation of behavior.

12. Zero-Cost Abstractions

Contexts introduce no runtime overhead.

All context operations are resolved and eliminated at compile time.

13. Separation of Structure and Behavior

Contexts contain only data and capabilities; functions contain only behavior.

Behavior never resides inside data.

14. Determinism

The result of a function is fully determined by its arguments and its context.

The context is part of the function’s contract.

15. Universal Applicability

The same mechanism applies uniformly to:

• architecture,
• dependency injection,
• ECS,
• effect management,
• global state modeling,
• systems and application code.

---

Paradigm Comparison

Object-Oriented Programming says:
Behavior belongs to the object.

Functional Programming says:
Behavior is a pure function.

Contextual Structural Programming says:
Behavior is a function operating within a structured context.

Contextual Structural Programming is not a mixture of OOP syntax with FP semantics.
It is a structural unification of the core ideas of both paradigms, achieved by replacing their weakest abstractions with a shared one: context.

---

What Is Taken from Object-Oriented Programming

1. Locality of Data

OOP idea:
Behavior operates in a local data environment (this).

In CSP:
A function operates within a context that provides local data directly.

• No parameter threading
• No global state
• No object mutation

Context provides object-like locality without objects.

2. Implicit Access to the Environment

OOP idea:
Methods implicitly access object fields.

In CSP:
Functions implicitly access context properties through lexical scope.

This preserves:

• readability,
• low boilerplate,
• direct access to relevant data,

while avoiding:

• hidden dependencies,
• runtime binding,
• mutable object state.

3. Composition over Inheritance

OOP idea (best practice):
Prefer composition over inheritance.

In CSP:
Contexts are composed structurally.

• No inheritance hierarchy
• No base classes
• No virtual dispatch

Composition is explicit, static, and structural.

4. Encapsulation of Infrastructure

OOP idea:
Infrastructure details should not pollute domain logic.

In CSP:
Infrastructure lives in contexts, not in domain types.

• Domain models remain pure
• Infrastructure is available only where explicitly required
• No wrapper objects or service locators

---

What Is Taken from Functional Programming

1. Functions as the Primary Unit of Behavior

FP idea:
Behavior is expressed as functions, not methods.

In CSP:
All behavior is implemented as functions.

• No methods
• No objects with behavior
• No hidden state transitions

2. Value Semantics

FP idea:
State evolves by creating new values, not mutating existing ones.

In CSP:
Contexts have value semantics.

• Contexts are not mutated implicitly
• Changes are expressed by constructing new contexts
• Referential reasoning is preserved

This prevents the implicit temporal coupling common in OOP.

3. Explicit Effects

FP idea:
Effects should be explicit in function signatures.

In CSP:
Effects are expressed as required contexts.

• IO is not hidden
• Infrastructure access is visible
• Capabilities are statically checked

This replaces monads with a structural mechanism.

4. Determinism and Reasoning

FP idea:
A function’s behavior is determined by its inputs.

In CSP:
A function’s behavior is determined by:

• its arguments, and
• its required context.

The context is part of the function’s contract.

---

What CSP Explicitly Rejects from Both

From OOP:

• Mutable objects as the unit of behavior
• Inheritance as a composition mechanism
• Runtime polymorphism as a default
• Hidden this-based dependencies

From FP:

• Mandatory parameter threading
• Reader / IO monads as architectural glue
• Effect modeling via control-flow encodings
• Indirect access to environment data

---

Why Context Is the Unifying Abstraction

• For OOP, context replaces objects
• For FP, context replaces environment threading and monads
• For architecture, context replaces DI containers
• For ECS, context replaces entity-component storage
• For effects, context replaces implicit runtime behavior

Context absorbs the useful properties of both paradigms while eliminating their pathological cases.

---

One-Sentence Summary

Object-Oriented Programming attaches behavior to mutable objects.
Functional Programming separates behavior from data.
Contextual Structural Programming keeps behavior functional while restoring object-like locality through explicit, typed contexts.

This is not OOP + FP.
It is a shared abstraction that subsumes both.

---

[lpil]

Hello! Thanks for the overview of implicit arguments in programming.

If you would like to make a proposal for an addition to Gleam you'll need to do include the information detailed in this article, so we can reason about what to add and why. https://lpil.uk/blog/how-to-add-metaprogramming-to-gleam/

Note the post is about metaprogramming proposals, but it applies to all language feature proposals.

[Pragrammist]

---

Problem: Environment and Context Propagation in Real-World Gleam Code 2

Background

In real-world Gleam applications (web backends, bots, workers, background jobs), it is common to work with an application environment that contains infrastructure data such as:

• configuration,
• database connections,
• loggers,
• external service clients,
• runtime metadata.

A typical pattern is to define an AppContext record and pass it through the application.

pub type AppContext {
  AppContext(
    db: Db,
    logger: Logger,
    config: Config,
  )
}

This context is then threaded through most functions.

---

The Problem

1. Context Must Be Passed Through Functions That Do Not Fully Need It

In practice, many functions only require a small subset of the application context, but are forced to accept the entire context record.

pub fn handle(req: Request, ctx: AppContext) {
  validate(req, ctx)
}

fn validate(req: Request, ctx: AppContext) {
  ctx.logger.info("validating request")
}

In this example, validate/2 only needs logger, but its signature suggests a dependency on the full AppContext.

As the application grows, this leads to:

• function signatures that overstate their actual dependencies,
• reduced local reasoning about what a function really needs,
• accidental coupling to unrelated infrastructure.

---

2. Manually Passing Only Required Fields Does Not Scale Well

One alternative is to pass only the required fields:

fn validate(req: Request, logger: Logger) {
  logger.info("validating request")
}

However, this approach introduces new problems:

• significant argument plumbing across many layers,
• repetitive changes when a function’s requirements evolve,
• friction when refactoring call chains.

In larger codebases this becomes difficult to maintain.

---

3. Creating Smaller Context Records Adds Boilerplate and Duplication

Another common approach is to define smaller context records:

pub type LoggerContext {
  LoggerContext(logger: Logger)
}

But this leads to:

• duplication of context definitions,
• additional conversion code,
• unclear relationships between contexts,
• more cognitive overhead for readers.

---

4. Modules Hide Dependencies Instead of Making Them Explicit

Some codebases rely on modules to provide implicit access to environment data.

While this avoids argument passing, it has downsides:

• dependencies are hidden from function signatures,
• effects are not visible to the type system,
• reasoning about testability and side effects becomes harder.

This works against Gleam’s emphasis on explicitness and predictability.

---

5. Reader-Style Patterns Are Verbose and Indirect

Reader-like abstractions can model environment access functionally, but in practice they:

• add syntactic and conceptual overhead,
• obscure simple data access behind indirection,
• make straightforward code harder to read.

For many users, this is too heavy-weight for common application logic.

---

Summary of the Pain

In current Gleam code, developers often face a trade-off:

• either explicitly pass large context records everywhere,
• or hide dependencies in modules or abstractions,
• or accept significant boilerplate and friction.

There is currently no language-level mechanism to:

• express that a function requires some environment,
• specify which parts of that environment it depends on,
• while avoiding explicit argument threading and hidden globals.

---

Desired Properties of a Solution

A solution to this problem should:

• allow functions to express minimal environment requirements,
• keep dependencies explicit and visible in function signatures,
• avoid implicit global state,
• avoid excessive argument plumbing,
• preserve Gleam’s goals of predictability, readability, and simplicity,
• not introduce runtime reflection or dynamic behavior.

---

Proposed Direction (High-Level)

This proposal explores treating context as a first-class language abstraction:

• A context represents a structural environment of data and capabilities.
• Functions declare which context they require.
• The compiler resolves and supplies the context from lexical scope.
• Contexts are created explicitly and have normal lexical lifetimes.
• Contexts are not mutated implicitly.

This aims to reduce boilerplate while keeping dependencies explicit and statically checked.

(Details of syntax and semantics would be discussed in subsequent sections.)

---

Why This Is a Language Problem

While similar patterns can be approximated with existing Gleam features, they all involve trade-offs that scale poorly in larger codebases.

This proposal argues that context propagation is a recurring, structural problem in real-world Gleam applications and may warrant language-level support rather than ad-hoc conventions.

[Pragrammist]

Contexts Are Useful for Business Logic, Not Only Infrastructure

While contexts are often discussed in relation to infrastructure (configuration, databases, IO), the same problem appears in business logic.

Business rules frequently depend on situational data:

• user role,
• permissions,
• feature flags,
• pricing rules,
• regional settings,
• application mode (test, preview, production).

These are not properties of domain entities themselves, but they influence how the same domain data should be interpreted or processed.

---

Business Logic Often Depends on Situational Context

Consider a simple domain model:

type Order {
  Order(
    total: Int,
    status: Status
  )
}

A business rule such as “can this order be refunded?” is not purely a function of Order.

It may depend on:

• the user role,
• whether the system is in preview mode,
• regional regulations,
• feature flags.

---

Current Approaches Force Context Into Types or Arguments

Passing Flags Explicitly

fn can_refund(order: Order, is_admin: Bool, region: Region) -> Bool {
  case order.status {
    Completed -> is_admin && region != EU
    _ -> False
  }
}

Problems:

• function signature grows with every new condition,
• callers must always supply values, even if irrelevant,
• refactoring becomes painful as requirements evolve.

---

Embedding Logic Into Domain Types

Another approach is to push logic into the domain:

fn can_refund(order: Order) -> Bool {
  order.status == Completed
}

But this forces:

• business rules to ignore real-world constraints,
• or domain types to be polluted with situational logic.

This breaks separation of concerns.

---

Contexts Allow Business Logic to Stay Pure and Adaptive

With contexts, business logic can depend on explicit, structured environment, without modifying domain types or bloating signatures.

---

Define Business Contexts

context RefundPolicyContext {
  user_role: Role
  region: Region
}

---

Business Logic Declares Its Requirements

fn can_refund(order: Order) with RefundPolicyContext -> Bool {
  case order.status {
    Completed ->
      user_role == Admin && region != EU

    _ ->
      False
  }
}

Key points:

• Order remains pure and unchanged,
• the function explicitly declares what external factors affect it,
• no unnecessary parameters are passed around.

---

Same Domain Logic, Different Behavior in Different Contexts

Context 1: Admin in US

let admin_us = context RefundPolicyContext {
  user_role: Admin
  region: US
}

can_refund(order)
// returns True

---

Context 2: Regular User in US

let user_us = context RefundPolicyContext {
  user_role: User
  region: US
}

can_refund(order)
// returns False

---

Context 3: Admin in EU

let admin_eu = context RefundPolicyContext {
  user_role: Admin
  region: EU
}

can_refund(order)
// returns False

The same function:

• same inputs,
• same domain model,
• different behavior only because the context changes.

This behavior is:

• explicit,
• statically checked,
• visible in the function signature.

---

Contexts Avoid Encoding Business Variants Into Types

Without contexts, developers are often forced to:

• add flags to domain models,
• create multiple variants of the same function,
• introduce conditional logic far from where it belongs.

Contexts allow business variation to be expressed:

• locally,
• declaratively,
• without multiplying types or parameters.

---

Business Logic Evolves Like Infrastructure

Just like infrastructure, business rules evolve over time:

• new regulations,
• new pricing models,
• new user roles,
• A/B experiments.

Contexts allow this evolution without:

• rewriting domain types,
• changing unrelated code,
• widening every function signature.

---

Summary

• Business logic often depends on situational data.
• That data does not belong to domain entities.
• Encoding it into types or arguments causes friction and duplication.
• Contexts allow business rules to depend on external conditions explicitly and locally.
• The same domain logic can behave differently in different contexts, without losing purity or clarity.

---

Key Takeaway

Types describe what something is.
Contexts describe how it should be interpreted here.

Both infrastructure and business logic benefit from treating context as a first-class abstraction.

[Pragrammist]

---

Composing Multiple Application Layers Using Contexts (Without Changing Types)

In real applications, code is naturally split into layers:

• Domain — core data structures
• Business logic — rules and decisions
• Application logic — orchestration and workflows
• Infrastructure — databases, APIs, external systems
• Transport/UI — HTTP, CLI, UI frameworks

A recurring problem is how to connect these layers without:

• polluting domain types,
• widening function signatures,
• introducing wrapper objects,
• or duplicating similar types for each layer.

---

Domain Types Remain Stable

The domain model should not change when new layers are added.

type Account {
  Account(
    id: String,
    status: Status,
    balance: Int
  )
}

This type contains only domain data.
No infrastructure fields.
No business flags.
No transport metadata.

---

Business Rules Depend on Business Context

Business logic often depends on situational rules.

context AccountPolicyContext {
  user_role: Role
  region: Region
}

fn can_withdraw(account: Account, amount: Int)
  with AccountPolicyContext
  -> Bool
{
  amount <= account.balance
    && user_role == Admin
    && region != Restricted
}

Here:

• Account is unchanged,
• business rules are explicit,
• behavior depends on context, not on type changes.

---

Application Layer Adds Workflow Context

Now consider application-level orchestration.

context TransactionContext {
  request_id: String
  timestamp: Int
}

fn process_withdrawal(account: Account, amount: Int)
  with AccountPolicyContext, TransactionContext
{
  if can_withdraw(account, amount) {
    execute_withdrawal(account, amount)
  }
}

No new arguments.
No type changes.
The function simply declares what layers it depends on.

---

Infrastructure Layer Adds Capabilities

Infrastructure concerns are introduced separately.

context PersistenceContext {
  db: Db
}

fn execute_withdrawal(account: Account, amount: Int)
  with PersistenceContext
{
  db.update_balance(account.id, account.balance - amount)
}

Infrastructure does not leak into:

• domain types,
• business rules,
• higher-level logic.

---

Transport / UI Layer Adds Presentation Context

Now the same domain logic is used in a transport layer.

context HttpContext {
  request: HttpRequest
  response: HttpResponse
}

fn handle_withdraw_request(account: Account, amount: Int)
  with AccountPolicyContext,
       TransactionContext,
       PersistenceContext,
       HttpContext
{
  process_withdrawal(account, amount)
  response.send_ok()
}

Again:

• no wrapper types,
• no “AccountWithHttp”,
• no mutation of domain structures.

---

How Contexts Are Composed Explicitly

Contexts are composed where layers meet.

fn handle_http_request(req: HttpRequest) {
  let policy_ctx = context AccountPolicyContext {
    user_role: req.user.role
    region: req.user.region
  }

  let tx_ctx = context TransactionContext {
    request_id: req.id
    timestamp: now()
  }

  let infra_ctx = context PersistenceContext {
    db: connect_db()
  }

  let http_ctx = context HttpContext {
    request: req
    response: make_response()
  }

  handle_withdraw_request(account, amount)
}

Each layer:

• is introduced explicitly,
• has a clear lifetime,
• can be tested independently.

---

Same Domain, Same Functions, Different Layer Combinations

The same business logic can be reused in different environments.

CLI tool

fn cli_withdraw(account, amount)
  with AccountPolicyContext, PersistenceContext
{
  process_withdrawal(account, amount)
}

Background job

fn scheduled_withdrawal(account, amount)
  with AccountPolicyContext, TransactionContext, PersistenceContext
{
  process_withdrawal(account, amount)
}

No changes to:

• Account,
• can_withdraw,
• execute_withdrawal.

Only the available context differs.

---

Why This Is Hard to Achieve with Types Alone

Without contexts, developers typically resort to:

• large “environment” records,
• multiple near-identical context types,
• wrapper objects per layer,
• deeply nested data structures,
• manual argument plumbing.

All of these approaches:

• increase coupling,
• reduce clarity,
• make evolution harder.

---

What Contexts Provide Instead

Contexts allow layers to be:

• orthogonal — each layer introduces its own concerns,
• composable — layers can be combined as needed,
• non-invasive — domain types remain untouched,
• explicit — dependencies are visible in signatures,
• local — scope determines availability.

---

Key Insight

Types define what data is.
Contexts define which layers are active here.

By separating these concerns, layers can be connected and recombined without rewriting domain models or widening APIs.

---

One-Sentence Summary

Contexts allow multiple application layers to be composed around stable domain types, enabling behavior to emerge from the environment rather than from changes to the data itself.

---

[Pragrammist]

---

Composing Multiple Application Layers Using Contexts (Without Changing Types)

In real applications, code is naturally split into layers:

• Domain — core data structures
• Business logic — rules and decisions
• Application logic — orchestration and workflows
• Infrastructure — databases, APIs, external systems
• Transport/UI — HTTP, CLI, UI frameworks

A recurring problem is how to connect these layers without:

• polluting domain types,
• widening function signatures,
• introducing wrapper objects,
• or duplicating similar types for each layer.

---

Domain Types Remain Stable

The domain model should not change when new layers are added.

type Account {
  Account(
    id: String,
    status: Status,
    balance: Int
  )
}

This type contains only domain data.
No infrastructure fields.
No business flags.
No transport metadata.

---

Business Rules Depend on Business Context

Business logic often depends on situational rules.

context AccountPolicyContext {
  user_role: Role
  region: Region
}

fn can_withdraw(account: Account, amount: Int)
  with AccountPolicyContext
  -> Bool
{
  amount <= account.balance
    && user_role == Admin
    && region != Restricted
}

Here:

• Account is unchanged,
• business rules are explicit,
• behavior depends on context, not on type changes.

---

Application Layer Adds Workflow Context

Now consider application-level orchestration.

context TransactionContext {
  request_id: String
  timestamp: Int
}

fn process_withdrawal(account: Account, amount: Int)
  with AccountPolicyContext, TransactionContext
{
  if can_withdraw(account, amount) {
    execute_withdrawal(account, amount)
  }
}

No new arguments.
No type changes.
The function simply declares what layers it depends on.

---

Infrastructure Layer Adds Capabilities

Infrastructure concerns are introduced separately.

context PersistenceContext {
  db: Db
}

fn execute_withdrawal(account: Account, amount: Int)
  with PersistenceContext
{
  db.update_balance(account.id, account.balance - amount)
}

Infrastructure does not leak into:

• domain types,
• business rules,
• higher-level logic.

---

Transport / UI Layer Adds Presentation Context

Now the same domain logic is used in a transport layer.

context HttpContext {
  request: HttpRequest
  response: HttpResponse
}

fn handle_withdraw_request(account: Account, amount: Int)
  with AccountPolicyContext,
       TransactionContext,
       PersistenceContext,
       HttpContext
{
  process_withdrawal(account, amount)
  response.send_ok()
}

Again:

• no wrapper types,
• no “AccountWithHttp”,
• no mutation of domain structures.

---

How Contexts Are Composed Explicitly

Contexts are composed where layers meet.

fn handle_http_request(req: HttpRequest) {
  let policy_ctx = context AccountPolicyContext {
    user_role: req.user.role
    region: req.user.region
  }

  let tx_ctx = context TransactionContext {
    request_id: req.id
    timestamp: now()
  }

  let infra_ctx = context PersistenceContext {
    db: connect_db()
  }

  let http_ctx = context HttpContext {
    request: req
    response: make_response()
  }

  handle_withdraw_request(account, amount)
}

Each layer:

• is introduced explicitly,
• has a clear lifetime,
• can be tested independently.

---

Same Domain, Same Functions, Different Layer Combinations

The same business logic can be reused in different environments.

CLI tool

fn cli_withdraw(account, amount)
  with AccountPolicyContext, PersistenceContext
{
  process_withdrawal(account, amount)
}

Background job

fn scheduled_withdrawal(account, amount)
  with AccountPolicyContext, TransactionContext, PersistenceContext
{
  process_withdrawal(account, amount)
}

No changes to:

• Account,
• can_withdraw,
• execute_withdrawal.

Only the available context differs.

---

Why This Is Hard to Achieve with Types Alone

Without contexts, developers typically resort to:

• large “environment” records,
• multiple near-identical context types,
• wrapper objects per layer,
• deeply nested data structures,
• manual argument plumbing.

All of these approaches:

• increase coupling,
• reduce clarity,
• make evolution harder.

---

What Contexts Provide Instead

Contexts allow layers to be:

• orthogonal — each layer introduces its own concerns,
• composable — layers can be combined as needed,
• non-invasive — domain types remain untouched,
• explicit — dependencies are visible in signatures,
• local — scope determines availability.

---

Key Insight

Types define what data is.
Contexts define which layers are active here.

By separating these concerns, layers can be connected and recombined without rewriting domain models or widening APIs.

---

One-Sentence Summary

Contexts allow multiple application layers to be composed around stable domain types, enabling behavior to emerge from the environment rather than from changes to the data itself.

---

[lpil]

I'm going to close this as spam. Please feel free to open a new discussion, but refrain from generating text in future.