Effects

Effects are still one of Sounio’s defining ideas. The clearest current contract is simple: side effects belong in the type signature, and pure computation should stay separate from effectful boundaries whenever possible.

What is solid today

• The checked artifact advertises algebraic effects with handlers as a language feature.
• The public docs should treat explicit with ... clauses as real, user-visible syntax rather than as an internal detail.
• For everyday programs, the most important concrete effect is still IO, because it shows up in simple examples and public fixtures.

Basic pattern

fn double(x: i32) -> i32 {
    x * 2
}

fn greet() with IO {
    println("Hello")
}

Where the work lives in the repo

• self-hosted/check/effects.sio handles effect-aware checking in the self-hosted path.
• self-hosted/effects/types.sio, self-hosted/effects/checker.sio, and self-hosted/effects/handlers.sio map the dedicated effect implementation surface.
• docs/architecture/EFFECT_HANDLERS_IMPLEMENTATION.md is still useful for broader design context, but implementation truth should come from the current self-hosted tree and checked fixtures.

How to document effects accurately

• Document the explicit signature requirement first.
• Describe richer handler semantics as design-plus-implementation work unless you have a current fixture proving the exact behavior you are claiming.
• Keep effectful logic at the edge of examples so readers can see the distinction between pure transforms and real-world interaction.