6. Procedures and rules

Level: beginner · Reading time: 14 min · Prerequisite: book/chapters/05-types.html · Track: essential · Maturity: reviewed · Last review: 2026-05-09

Prerequisites: book/chapters/05-types.html. See also: book/chapters/05-types.html, book/chapters/27-grammar.html, book/chapters/31-build-errors.html.

Concrete Problem

Procedure chapters often explain signatures and bodies separately, so readers miss how a complete procedure contract works.

Red Thread (Single Project)

A small service procedure validates input, transforms it, and returns an observable result.

For what

This chapter helps the reader design procedures as explicit contracts.

What you are going to do

You will read one complete procedure flow, identify where the contract begins and ends, then inspect a broken variant.

Coherent example

space demo/procedures

proc normalize_score(raw: int) -> int {
  if raw < 0 { give 0 }
  if raw > 100 { give 100 }
  give raw
}

Global explanation

A procedure chapter should teach one stable idea: the signature, the branch logic, and the returned result are one contract. The reader should not have to infer what comes back from the procedure.

Invalid case

proc broken_score(raw: int) {
  if raw < 0 { give 0 }
}

This invalid case is intentionally small. It exists to isolate the contract failure that the chapter is trying to teach.

Common pitfalls

• Showing signatures without a meaningful body.
• Using procedures to hide global state instead of exposing a clean contract.
• Failing to explain how the result remains observable and testable.

Short exercise

Add one extra input parameter and keep the procedure contract as readable as before.

Summary in 5 points

1. A procedure is a full contract, not just a named block.
2. The signature and the result shape belong together.
3. Branch logic should remain visible inside the procedure.
4. Broken procedures usually hide a missing contract part.
5. A good example is small but complete.