resume and abort
By default, the expression of a handler clause is the value returned to perform.
Sometimes the handler needs to do work before deciding which value to return —
validate, log, count. resume(v) shortens that path: the handler executes whatever
it needs and only then resumes the computation with v as the result of perform:
Ask::ask handler records the question in a list and then resumes with the correct answer.
// Feature: explicit `resume(v)` — short-circuit the arm with `v` as the
// value returned to `perform`. Lets a handler do work before resuming
// (log, validate, count) without coupling the body's last expression to
// the resume value.
// Syntax: `resume(v)` is reserved inside any `handle ... with { ... }`
// arm body. Outside an arm body it falls through to be treated as an
// ordinary call (so user code that defines a `resume` fn still works).
// When to use: you want the handler to do something *before* handing
// control back, or branch on the operation args before deciding what
// value to send back.
effect Ask {
fn ask(question: str) -> str
}
fn survey() with Ask -> str {
let name = perform Ask::ask("What is your name?")
let color = perform Ask::ask("What is your favourite colour?")
return "{name} likes {color}"
}
let asked = []
let answer = handle survey() with {
Ask::ask(q) => {
asked.push(q)
// Do work first, then resume with a chosen default.
if q.contains("name") {
resume("Alice")
}
resume("blue")
},
}
print(answer)
for q in asked { print("- asked: {q}") }
// expected:
// Alice likes blue
// - asked: What is your name?
// - asked: What is your favourite colour?
Sometimes there is no reasonable value to return to perform — the operation failed
and the continuation would be useless. abort(v) discards the entire pending
continuation and makes v become the result of the whole handle expression. It is
equivalent to a long-distance throw/return, without having to thread Result<T, E>
through the entire call chain:
Fail::fail calls abort(-1); the happy path yields the normal sum, the error path returns -1.
// Feature: terminal handlers via `abort(v)` — discards the
// continuation; `v` becomes the value of the enclosing `handle`
// expression. Equivalent to `throw`/`return` of long distance, without
// exceptions or `Result<T, E>` wiring.
// Syntax: `abort(v)` is reserved inside any `handle ... with { ... }`
// arm body. It's tagged with the *specific* handle frame, so a terminal
// arm aborts only to its own `handle` — never to an outer one.
// When to use: failure paths, early exits, parse errors — anywhere the
// continuation would be useless because the operation can't sensibly
// return a value of the declared type.
effect Fail {
fn fail(reason: str) -> int
}
fn parse_int(s: str) with Fail -> int {
// Tiny mock-parser: accept "1".."5" — anything else fails.
if s == "1" { return 1 }
if s == "2" { return 2 }
if s == "3" { return 3 }
if s == "4" { return 4 }
if s == "5" { return 5 }
perform Fail::fail("not in 1..5: {s}")
return 0 // unreachable: handler aborts
}
fn sum_of(inputs: [str]) with Fail -> int {
var total = 0
for s in inputs {
total = total + parse_int(s)
}
return total
}
// Happy path: every input parses → normal resume of -1 never happens.
let ok = handle sum_of(["1", "2", "3"]) with {
Fail::fail(_r) => abort(-1),
}
print("ok: {ok}")
// expected: ok: 6
// Bad input: handler aborts the whole sum with -1 as the result.
let bad = handle sum_of(["1", "oops", "3"]) with {
Fail::fail(reason) => {
print("- aborted: {reason}")
abort(-1)
},
}
print("bad: {bad}")
// expected:
// - aborted: not in 1..5: oops
// bad: -1
The difference is conceptual: resume continues the computation with a value; abort
terminates it. Both are used inside a handler clause and affect only the handle
frame that installed them — an abort never escapes to an outer handler.
Challenge
In 08-terminal-handlers.zolo, add a warn(msg: str) operation to the effect and
use resume(0) in the matching clause. What changes in the flow?
See also