Keyword `let`

let is documented here as a full reference entry: grammatical role, semantics, canonical form, valid example, counter-example, diagnostics, interactions, and design notes.

Visual anchor: each page now has its own wiki-style profile image. It shows a small code excerpt where let appears in its most recognizable form.

Quick navigation: use the previous, summary, and next links to move through the full keyword series without manually returning to the index.

Summary

Overview
Definition
Grammatical role
Canonical syntax
Detailed semantics
Specific profile
Effect on execution
Valid variants
Vitte example
Guided reading of the example
Comparison with C
Recommended uses
Invalid example and diagnostic
Common errors
Neighbor keywords
Common misreadings
Implementation notes
Presence in the book

Overview

Field	Value
Keyword	`let`
Family	Binding and mutation
Suggested level	Beginner
Main neighbor	`set`
Short role	`let` is a binding or assignment keyword that changes how local state is introduced or updated.
Main effect	`let` acts on the program's local state by introducing or modifying a named value that subsequent instructions will read.

The keyword let acts on the visible state of a block. It introduces, initializes, or modifies a value, which makes it a critical point for invariant readability.

A useful encyclopedic reading should answer three questions: where can let appear, what does it change in the block contract, and how does the compiler signal misuse?

Definition

let is a binding or assignment keyword that changes how local state is introduced or updated.

The keyword let acts on the visible state of a block. It introduces, initializes, or modifies a value, which makes it a critical point for invariant readability.

Grammatical role

Introduces an initialized local binding.

This grammatical role is essential: if a reader understands the structural place of let, they already understand much of the diagnostics that will appear when it is moved or truncated.

Canonical syntax

Canonical form: `let name: type = value`.

The canonical form matters because it gives the compiler and the reader the same reference structure. A large share of diagnostics related to let come from an abbreviated, displaced, or incomplete form.

Detailed semantics

Semantically, let evolves the state of a local name. It should therefore be read together with scope, lifetime, and the distinction between introducing a value and updating an existing one.

In an encyclopedic reading, let should not be reduced to a dictionary definition. Its effect on scope, block shape, value visibility, control progression, and the diagnostic family it activates when misused must also be considered.

Specific profile

Local binding introduction keyword. It makes the birth of a name explicit and is often the first level of readability in a block.

Design notes

With `let`, the key question is not only 'which value?' but 'why does this name exist now?'
A good local binding reduces the cognitive load of the block instead of deferring it into a later mutable state.

Reading questions

Why does this value deserve a name?
Is the scope of the name short enough to remain obvious?
Does the declaration clarify the contract or merely add one more variable?

Targeted anti-patterns

Multiplying disposable `let` bindings whose only purpose is to artificially split a simple expression.
Naming a local binding too vaguely and losing the explanatory benefit of its introduction.

Effect on execution

let acts on the program's local state by introducing or modifying a named value that subsequent instructions will read.

In other words, the presence of let is not merely syntactic: it helps the reader predict what will be executed, produced, exposed, or forbidden from this point in the program.

Valid variants

`let name: type = value`
`let name = value` when local inference is allowed

These variants are not free synonyms. They indicate the legitimate forms from which one can reason about diagnostics, scope differences, or contract readability.

Vitte example

proc read_counter() -> int {
  let value: int = 1
  give value
}

This example shows let in a nominal context. It should be read globally: where the contract begins, which values are constrained, which output becomes observable, and why the presence of the keyword is justified.

Guided reading of the example

First locate the full construction that contains let, not the isolated word.
Then identify which contract becomes visible because of let: type, branch, binding, module, exit, or advanced boundary.
Finish by checking the observable effect produced by the construction that contains let.
For a binding keyword, distinguish name introduction, mutation, and value scope.

This guided reading is intentionally closer to a reference page than to a tutorial: it helps reconstruct the exact role of let in a complete block.

Comparison with C

/* C comparison: declarations and assignments are usually split across local variables and direct assignment. */

For this keyword, the parallel with C remains approximate. The comparison mainly indicates that in C the same idea is often spread across file conventions, operators, or less explicit control structures.

The source of truth remains Vitte grammar and semantics. The comparison with C should be read as a cultural marker, not as a parallel specification.

Recommended uses

let deserves to appear when it simplifies the reading of the block's global contract, not when it merely adds one more surface form.

When to use it

When let makes the block contract more explicit at first reading.
When it reduces the number of implicit assumptions the reader must reconstruct mentally.
When local state must be introduced or modified without ambiguity about the name's scope.

When to avoid it

Avoid let when another, more precise keyword already carries the block's intent.
Avoid let when it adds only surface noise without clarifying the contract.
Avoid reading or teaching it as an isolated token with no relation to the full structure.

Common pitfalls

Using let in a grammatical layer where it does not belong.
Confusing the role of the keyword with the role of the full surrounding block.
Showing only the nominal form and never how the contract fails.

Invalid example and diagnostic

proc bad_let() -> int {
  let
  give 0
}

The binding surface is incomplete or appears in the wrong form.

The counter-example is not merely wrong: it is wrong in an instructive way. It shows which grammar or execution-contract assumption is no longer accepted when let is moved, truncated, or combined with the wrong context. Concretely, the local binding is introduced in an incomplete form.

A good encyclopedic counter-example does not show arbitrarily broken code: it isolates the precise reason why let can no longer support the expected contract. Its teaching value is diagnostic before it is syntactic.

Common compilation errors

Typical message	Usual cause	Fix
`unexpected token near let`	The keyword appears in an invalid form or grammatical layer.	Return to the canonical form and verify placement and delimiters.
`type mismatch`	The keyword participates in a block whose value contract is incoherent.	Realign the surrounding types, branches, or produced values.
`invalid construct`	The keyword is present but the surrounding construction is incomplete.	Restore the missing branch, declarative part, or operands.

This table does not replace the compiler's exact diagnostics. It serves as a mental map: when let fails, the problem usually comes from an invalid grammatical form, an incoherent type contract, or an incomplete construction.

Neighbor keywords

Keyword	Operational difference
`set`	Direct neighboring keyword: it helps explain what `let` does, either by contrast or by complement.
`set`	The first introduces a binding, the second modifies it.
`make`	Creation/initialization neighbor whose contract should be distinguished.

Comparison with neighboring keywords is essential on a wiki-style page: let is better understood when one knows precisely what it does not do.

Common misreadings

Confusing binding introduction with mutation of an existing binding.

Implementation and diagnostic notes

Common errors concern scope, illegal reassignment, or an incompatible type contract between introduction and use.
In a compiler, these keywords modify the local environment and mutability or assignment information.

Keyword let