Context

Issue #59 adds the <Async> marker effect with async/await built-in functions. In v0.0.82, Async follows the IO model (runtime-discharged, no handler needed). However, algebraic effects naturally support custom scheduling strategies via handlers.

Proposal

Allow handle[Async] blocks with custom scheduling semantics:

handle[Async] {
  async(@T) -> { ... },   -- custom "start" logic
  await(@Future<T>) -> { ... }  -- custom "resolve" logic
} in {
  -- body using async/await
}

This would enable:

• Sequential execution (current default — identity operations)
• Thread pool scheduling (via host imports)
• Event loop scheduling (via WASI 0.3 future<T> when available)
• Mock/test scheduling (deterministic ordering for tests)

Design considerations

1. Async currently has no operations (marker effect). Adding handler support would require either:
   • Promoting async/await to effect operations, or
   • Adding special handler clause syntax for built-in functions
2. The grammar currently requires handle blocks to have at least one clause. Empty clause lists would need parser changes.
3. This interacts with WASI 0.3 compliance (WASI 0.2 compliance #237) — the WASI 0.3 backend would be one scheduling strategy.

Priority

Post-WASI 0.3. The current sequential implementation is sufficient for the reference compiler. Custom schedulers become useful when true concurrency (WASI threads or async) is available.