5. Types and values
TL;DR (5 lines)
- Types are contracts, not decorations.
- A small form is a better teaching unit than isolated declarations.
- The chapter should connect type names to domain meaning.
- Invalid examples should show broken contracts clearly.
- Type clarity reduces later diagnostic work.
Frequent mistakes
- Using a type by habit instead of by domain meaning.
- Explaining individual fields without explaining the full contract.
- Forgetting that invalid examples should show a broken meaning, not just a weird token.
Prerequisites: book/chapters/04-syntaxe.html. See also: book/chapters/04-syntaxe.html, book/chapters/27-grammar.html, book/chapters/31-build-errors.html.
Concrete Problem
Readers often learn type names but not what type contracts buy them in a real block.
Red Thread (Single Project)
A tiny reporting example uses integers, strings, and a form to make value contracts visible.
For what
This chapter helps the reader choose types based on meaning, not habit.
What you are going to do
You will inspect a typed example, identify where each type contract matters, then compare it to an invalid variant.
Coherent example
space demo/types
form Report {
name: string
retries: int
ok: bool
}
proc score(r: Report) -> int {
if not r.ok { give 0 }
give r.retries + 1
}
Global explanation
The value of the chapter is not the list of types. It is the way each type removes ambiguity from the block: text is text, counters are numeric, flags are boolean, and the compiler can enforce that split.
Invalid case
proc bad_report() -> int {
let name: int = "demo"
give name
}
This invalid case is intentionally small. It exists to isolate the contract failure that the chapter is trying to teach.
Common pitfalls
- Using a type by habit instead of by domain meaning.
- Explaining individual fields without explaining the full contract.
- Forgetting that invalid examples should show a broken meaning, not just a weird token.
Short exercise
Take the example form and add one field whose meaning is obviously not numeric. Choose the type that makes the contract clearest.
Summary in 5 points
- Types are contracts, not decorations.
- A small form is a better teaching unit than isolated declarations.
- The chapter should connect type names to domain meaning.
- Invalid examples should show broken contracts clearly.
- Type clarity reduces later diagnostic work.
Mini quiz
- What contract is the coherent example trying to make explicit?
- Why does the invalid example fail?
- What boundary should remain visible if you extend the example?
See also
Next best action
Extend the coherent example by one small, justified step and keep the same contract visible from input to output.