Context in gleam

[Pragrammist]

---

Problem: Expressing and Propagating Execution Context in Gleam Applications

Hello!
I’d like to discuss a recurring problem I’ve encountered while building real-world Gleam applications (bots, backend services, integrations), and to get feedback on whether this is something that should remain a library-level concern or could benefit from language-level support.

---

Background

In non-trivial Gleam applications, functions often need access to execution context such as:

• configuration values,
• database connections,
• caches (e.g. Redis),
• external clients (HTTP, APIs),
• logging and metrics,
• business rules depending on environment or policy.

A common pattern is to represent this as a record and pass it explicitly.

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

---

Problem 1: Overly Wide Contexts in Function Signatures

Many functions only need a small subset of the context, but are forced to accept the entire record.

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

In this example, validate/2 only depends on logger, but its signature suggests a dependency on the full application environment.

As the context grows, this leads to:

• overstated dependencies,
• reduced local reasoning,
• accidental coupling between unrelated parts of the system.

---

Problem 2: Manually Passing Only Required Values Does Not Scale

An alternative is to pass only the required values:

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

This improves precision but introduces new issues:

• argument plumbing across multiple call layers,
• repetitive refactoring when requirements change,
• increased friction in larger codebases.

In practice, this quickly becomes cumbersome.

---

Problem 3: Smaller Context Types Lead to Duplication

Another approach is to define multiple smaller context records:

pub type LoggerContext {
  LoggerContext(logger: Logger)
}

While this improves precision, it also introduces:

• duplicated structures,
• conversion code between contexts,
• unclear relationships between similar environment types.

This becomes harder to maintain as the number of contexts grows.

---

Problem 4: Module-Level Access Hides Dependencies

While Gleam does not have implicit global mutable state, dependencies can still become implicit when accessed via modules or closures.

fn process(req) {
  logger.info("processing request")
}

Here, process/1 appears pure from its signature, but performs logging internally.
The dependency exists, but is not visible to the type system or the caller.

This makes:

• local reasoning harder,
• effects less explicit,
• refactoring more error-prone.

---

Problem 5: Business Logic Also Depends on Context

This is not limited to infrastructure.

Business rules often depend on situational data:

• user role,
• region,
• feature flags,
• application mode.

Example:

fn can_refund(order: Order, is_admin: Bool, region: Region) -> Bool { ... }

Over time, such functions accumulate flags and parameters that are not part of the domain model itself, but still influence behavior.

Embedding these concerns into domain types or widening signatures does not scale well.

---

Problem 6: Composing Independent Concerns Becomes Difficult

In practice, applications often interact with multiple independent systems:

• database,
• cache,
• external APIs,
• spreadsheets,
• metrics,
• logging.

These concerns are orthogonal, but current patterns tend to collapse them into a single “environment” record or scatter them across modules.

This makes it hard to:

• compose concerns flexibly,
• reuse logic in different execution environments,
• add new integrations without refactoring unrelated code.

---

Summary of the Problem

In current Gleam applications, developers must choose between:

• passing large context records everywhere,
• manually plumbing many arguments,
• duplicating context types,
• or hiding dependencies behind modules.

There is currently no way to:

• express minimal context requirements per function,
• keep dependencies explicit and statically visible,
• compose multiple independent concerns without widening types.

---

Desired Properties of a Solution

A potential solution should:

• allow functions to declare what environment they require,
• keep dependencies explicit and visible,
• avoid implicit global state,
• avoid excessive argument plumbing,
• preserve Gleam’s predictability and readability,
• have clear, static semantics.

---

Open Question

Is this class of problems something that Gleam intentionally leaves to library-level patterns, or could it benefit from a language-level abstraction for expressing and propagating execution context?

---

---

Possible Direction: Treating Context as a First-Class Language Abstraction

Based on the problems described above, one possible direction is to treat execution context as a first-class language concept, rather than modeling it indirectly via records, modules, or argument plumbing.

This section outlines a possible approach, focusing on expressiveness and clarity, not on final syntax or implementation details.

---

Core Idea

A context represents a structured environment of data and capabilities that is:

• created explicitly,
• scoped lexically,
• composed from smaller contexts,
• and required explicitly by functions.

Functions declare what context they need, rather than how it is passed.

---

Example 1: Infrastructure Context (Logging)

context LoggingContext {
  logger: Logger
}

fn validate_request(req: Request)
  with LoggingContext
{
  logger.info("validating request")
}

Key properties:

• the dependency on logging is explicit,
• no logger argument is threaded through the call chain,
• the function signature accurately reflects its effect.

---

Example 2: Business Logic Context (Policy)

context RefundPolicyContext {
  user_role: Role
  region: Region
}

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

Here:

• the domain type Order remains unchanged,
• business rules depend on situational context,
• behavior varies by context, not by type mutation.

---

Example 3: Same Function, Different Behavior

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

can_refund(order) // true

let user_eu = context RefundPolicyContext {
  user_role: User
  region: EU
}

can_refund(order) // false

The function:

• is pure with respect to its arguments,
• but adapts behavior based on explicitly declared context.

---

Example 4: Independent Data Sources (Vertical Concerns)

context DbContext {
  db: Db
}

context RedisContext {
  redis: Redis
}

fn load_account(id: String)
  with DbContext, RedisContext
  -> Account
{
  case redis.get(id) {
    Some(account) -> account
    None -> db.load_account(id)
  }
}

Database and cache are:

• independent,
• composable,
• optional,
• visible in the function’s requirements.

---

Example 5: External Integration (HTTP Client)

context HttpClientContext {
  http: HttpClient
}

fn notify_external(account: Account)
  with HttpClientContext
{
  http.post("/sync", account)
}

This dependency:

• is explicit,
• can be removed or replaced,
• does not affect unrelated code.

---

Example 6: Cross-Cutting Concerns (Metrics + Logging)

context MetricsContext {
  metrics: Metrics
}

fn record_sync(account: Account)
  with MetricsContext, LoggingContext
{
  metrics.increment("account.sync")
  logger.info("synced " <> account.id)
}

Cross-cutting concerns:

• are declared where used,
• do not leak into domain or unrelated logic.

---

Example 7: Composition Without a God Context

fn sync_account(id: String)
  with DbContext,
       RedisContext,
       HttpClientContext,
       MetricsContext,
       LoggingContext
{
  let account = load_account(id)
  notify_external(account)
  record_sync(account)
}

There is:

• no single AppContext,
• no unused dependencies,
• no hidden access via modules.

Each function sees only what it requires.

---

Example 8: Same Logic, Different Environments

Background Job

fn nightly_sync(id: String)
  with DbContext, MetricsContext, LoggingContext
{
  let account = db.load_account(id)
  record_sync(account)
}

CLI Tool

fn cli_sync(id: String)
  with DbContext, HttpClientContext
{
  let account = db.load_account(id)
  notify_external(account)
}

The same domain logic:

• reused in different execution contexts,
• without modifying types,
• without branching logic.

---

Example 9: Context Assembly at the Boundary

Contexts are created explicitly at system boundaries:

fn handle_request(req: HttpRequest) {
  let logging = context LoggingContext {
    logger: request_logger(req.id)
  }

  let db_ctx = context DbContext {
    db: connect_db()
  }

  let redis_ctx = context RedisContext {
    redis: connect_redis()
  }

  let http_ctx = context HttpClientContext {
    http: make_http_client()
  }

  sync_account(req.account_id)
}

This keeps:

• lifetimes explicit,
• ownership clear,
• effects localized.

---

Why This Is Different from Existing Patterns

Compared to current approaches, this model:

• avoids widening types to add new capabilities,
• avoids manual argument plumbing,
• avoids hidden module-level dependencies,
• preserves explicitness and static reasoning.

Contexts act as a structural layer between types and functions.

---

Summary

This approach allows:

• precise expression of dependencies,
• local evolution of capabilities,
• composition of independent concerns,
• reuse of logic across environments,
• without modifying domain types or introducing global state.

---

[Pragrammist]

---

How this differs from implicit arguments

At first glance, this proposal may resemble implicit arguments, but the overlap is mostly superficial.
The core idea goes beyond hiding function parameters.

What implicit arguments are

In language design terms, implicit arguments are:

Function parameters that are not passed explicitly at the call site and are instead resolved by the compiler from the surrounding scope.

Examples include:

• Scala implicit parameters
• Haskell implicit parameters / typeclass dictionaries
• Rust trait bounds resolved from scope

Key properties:

• They are still function parameters
• They exist to reduce syntactic noise
• They operate only at function-call level
• They do not introduce a new program structuring concept

---

Where the ideas overlap

There is genuine overlap in motivation:

1. Avoid passing environment everywhere
   Reducing boilerplate when threading configuration, logging, DB handles, etc.

2. Lexical resolution
   Required values are resolved from the surrounding scope.

3. Minimal requirements
   Functions depend only on the subset of data they actually use.

4. Context is part of the function contract
   The environment is type-checked and statically known.

These similarities explain why the idea can be misclassified as implicit arguments.

---

Where this proposal fundamentally differs

1. Context is not a parameter — it is a primary abstraction

Implicit arguments are still arguments.

This proposal treats context as a first-class language construct, not as a hidden parameter list.

Functions do not receive context.
They execute within a context.

This shifts the mental model from:

“calling a function with parameters”

to:

“executing behavior inside a structured environment”

---

2. Context composition and narrowing are language operations

Implicit arguments provide no notion of context algebra.

This proposal introduces:

• context composition
• structural merging
• automatic narrowing to required subsets

A function requiring { Logger, Db } can execute inside a larger { Logger, Db, Metrics, Cache } context without modification.

This is not parameter passing — it is structural compatibility between environments.

---

3. Flat accessibility, not navigational access

With implicit arguments, values are still accessed through identifiers tied to bindings:

logger.info(...)
config.timeout

This proposal models context as a flat lexical environment, where required properties become directly accessible:

info("message")
timeout

The context behaves like a locally injected scope, not an object or parameter bundle.

---

4. Context is both an environment and a value

Implicit arguments are not first-class values.

Here, a context can be:

• implicitly available
• explicitly passed
• returned from a function
• stored
• composed

Both implicit and explicit forms are equivalent and interoperable.

This duality does not exist in traditional implicit argument systems.

---

5. Universal applicability beyond functions

Implicit arguments apply only to function calls.

This proposal uses the same mechanism uniformly for:

• dependency injection
• effect control
• ECS-style systems
• global and local state modeling
• application and system-level architecture

It is not a convenience feature — it is an organizing principle.

---

Summary

A precise distinction would be:

Implicit arguments hide parameters.
Context-based programming introduces a typed, composable execution environment in which functions operate.

Or more directly:

Implicit arguments are a mechanism.
This proposal is a program model in which implicit resolution is only a consequence.

---

[Pragrammist]

Testability as a first-class property

One practical consequence of treating context as a language abstraction is that testability emerges naturally, without additional patterns or frameworks.

Context initialization defines the execution environment

In this model, behavior is constant, while context varies.

The same function can be executed in different environments simply by initializing a different context:

• production context
• test context
• in-memory context
• simulated or deterministic context

No mocking framework or dependency injection container is required.
The execution environment is constructed explicitly and locally.

---

No global state, no hidden wiring

Traditional approaches often rely on:

• global variables,
• mutable singletons,
• DI containers with runtime wiring,
• mocks that intercept calls indirectly.

With explicit contexts:

• there is no hidden global state,
• all side effects are routed through context capabilities,
• the compiler enforces availability and completeness.

A function cannot accidentally access production resources in a test unless the context explicitly provides them.

---

Testing by substitution, not interception

Testing becomes a matter of context substitution, not call interception.

For example:

• replace Db with InMemoryDb
• replace Logger with CollectingLogger
• replace Clock with DeterministicClock
• replace HttpClient with StubHttpClient

The function itself remains unchanged.

This avoids:

• mocking internals,
• fragile expectations,
• tests coupled to implementation details.

---

Minimal contexts improve test focus

Because functions declare minimal context requirements, tests only need to construct the subset that is actually used.

A function that requires { Account } does not need:

• database setup,
• logging configuration,
• environment variables,
• external services.

This leads to:

• faster tests,
• smaller fixtures,
• clearer intent.

---

Deterministic execution by construction

Since side effects are expressed exclusively through context:

• time,
• randomness,
• IO,
• external state

can all be controlled at the boundary.

Determinism is achieved by context design, not by convention.

---

Summary

Context-based programming does not add testability as a feature —
it removes the obstacles that usually make testing difficult.

Different execution environments are not simulated —
they are expressed directly as different contexts.

This applies uniformly across:

• unit tests,
• integration tests,
• local development,
• production execution.

[Pragrammist]

---

Core Principles of Context-Oriented Programming

1. Context as the Primary Abstraction

Programs are structured around contexts, not classes or modules.

A context represents a structured environment of data and capabilities in which functions execute.
Functions do not own state; they operate within a context.

---

2. Requirements Instead of Explicit Dependencies

Functions declare what they require from their environment, not how it is passed.

A function specifies the minimal set of data and capabilities it needs.
Dependency passing is a mechanical concern, handled by the language, not the programmer.

---

3. Automatic Lexical Context Propagation

Contexts are propagated automatically through lexical scope.

If a required context is available in the surrounding environment, it is implicitly bound.
No boilerplate threading of environment objects is required.

---

4. Structural Compatibility and Minimal Visibility

Context compatibility is structural, and visibility is minimal by default.

A function can operate in any context that structurally satisfies its requirements.
Only the required subset of the context is visible — no accidental access to unrelated data.

---

5. Explicit Effects via Context

All side effects are enabled explicitly through context.

IO, logging, persistence, time, randomness, and external interactions are not implicit.
A function can only perform effects that its context explicitly provides.

---

One-sentence summary (FP-style)

A program is a composition of pure functions executed within explicitly defined, structurally typed, and automatically propagated contexts.

---

Relationship to existing paradigms

• From Functional Programming

  • Pure functions
  • Explicit effects
  • Determinism by construction
  • Structural typing ideas

• From Object-Oriented Programming

  • Encapsulation of environment
  • Locality of access (this-like, but immutable)
  • Behavior reuse without inheritance

• What is new

  • Context is a first-class language abstraction
  • Dependency passing is implicit but statically checked
  • Effects are contextual, not global or hidden

---

[lpil]

Hello. This is a very large amount of generated context, and from skimming it I can see many inaccuracies. It is not possible to handle requests like these, it would take too much time.

I'm going to close this. Please feel to make a new issue, but you must not generate your posts, and you must be concise, otherwise it will be closed too.