Can PureScript's Effect and Aff monads be unified into a single effect-parameterized monad?

Short Answer

No, PureScript's Effect and Aff cannot be unified into a single effect-parameterized monad today without breaking changes. The phantom effect row tracks synchronous capabilities only; Aff's asynchronous scheduling, cancellation, and fiber semantics are runtime constructs that the row system does not capture. A true unification would require encoding async/cancellation into the type system and rewriting the runtime—a major design shift with no consensus.

Confirmed Facts

• Distinct types: Effect (in purescript-effect) and Aff (in purescript-aff) are separate newtypes with different constructors and no shared unified interface.
• Explicit lifting required: Moving a synchronous computation into an async context uses liftEffect :: Effect a -> Aff a. The boundary is intentional to keep blocking vs. non-blocking costs visible in types.
• No official unified monad: Core libraries do not provide a drop-in replacement for both.

Likely Explanations (Design Rationale)

Why the Boundary Exists

• Safety over convenience: The Effect/Aff split makes synchronous side effects and asynchronous cancellable work explicitly distinct. Conflating them risks accidental blocking in async code and hides performance characteristics.
• Runtime semantics differ: Aff uses a fiber scheduler with cancellation tokens, timeout handling, and parallel composition (parAff). These are not expressible as phantom row labels; they require a dedicated runtime.
• Phantom rows are type-level only: They track what effects may occur (e.g., CONSOLE, RANDOM), not how they execute. Adding async/cancellation to the row would turn a lightweight capability system into a full effect system with runtime implications.

What Unification Would Require

1. Extend the effect row with async/cancellation capabilities (e.g., ASYNC, CANCEL).
2. Rewrite the Aff runtime to interpret those capabilities instead of using its current fiber machinery.
3. Migrate every existing Effect and Aff API, breaking all downstream libraries.

This is why the existing phantom-row design does not permit a combined monad without breaking backward compatibility. A new unified monad could be introduced alongside the current two, but replacing them is a breaking change of ecosystem scale.

Criteria the Compiler Team Would Likely Apply

Criterion	Likely Weight
Backward compatibility	High — breaking core types requires a migration path for the entire ecosystem
Runtime performance	High — any unification must not degrade Aff's scheduling or cancellation guarantees
Type-level expressiveness	Medium — row system must cleanly model async/cancellation without exploding complexity
Boilerplate reduction	Low — convenience is a benefit, not a justification for breaking change
Community consensus	High — major type-system changes go through RFC process with broad review

Practical Recommendation for Library Authors

Design for the current split. Expose both Effect and Aff interfaces where appropriate, and use liftEffect at the boundary. This is stable, well-understood, and matches the ecosystem's direction. If a unified monad ever lands, it will likely arrive as an opt-in addition—not a replacement—giving libraries time to adopt gradually.

One Diagnostic Detail That Could Change This

If you are targeting a specific framework (e.g., purescript-halogen, purescript-react-basic) that already provides its own effect abstraction or unified monad, check its current API. Some frameworks layer their own effect types on top of Aff and may already offer the unification you want without waiting for core changes.