Effect System

Algebraic effects with handlers: checking, inference, and runtime dispatch.

Effect System

The effect system sits at the intersection of language design and active implementation. A comprehensive page needs to acknowledge the dedicated effect subsystem in the self-hosted tree while still keeping the public teaching contract centered on explicit with ... clauses.

Current source map

  • self-hosted/check/effects.sio covers effect-aware semantic checking.
  • self-hosted/effects/types.sio, checker.sio, and handlers.sio show the dedicated self-hosted implementation split.
  • docs/architecture/EFFECT_HANDLERS_IMPLEMENTATION.md remains useful as a broader design reference, but implementation truth should come from the current tree and verified behavior.

What public docs should emphasize

  • Effects are explicit in function signatures.
  • The IO effect remains the clearest everyday example for users.
  • The richer handler architecture exists in the repo and in design docs, but not every path should be presented as equally validated in the checked public artifact.

Signature-level effect tracking

fn read_config(path: string) -> string with IO {
    read_line()
}

Contributor guidance

  • If you are tracing effect behavior, start with the self-hosted checker file and then step into the dedicated effect modules.
  • If you are writing user docs, do not skip the signature-level contract just because the underlying implementation is more complex.
  • If you are documenting handlers, be explicit about whether you are describing the current checked path or the fuller design space.