Keyword make

Definition

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

The keyword make 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 explicit creation of a value or binding according to the local language convention.

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

Canonical syntax

Canonical form: `make 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 make come from an abbreviated, displaced, or incomplete form.

Detailed semantics

Semantically, make 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, make 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.

Effect on execution

make 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 make 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

• `make name: type = value`.

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 build_flag() -> int {
  make value: int = 1
  give value
}

This example shows make 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

1. First locate the full construction that contains make, not the isolated word.
2. Then identify which contract becomes visible because of make: type, branch, binding, module, exit, or advanced boundary.
3. Finish by checking the observable effect produced by the construction that contains make.
4. 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 make 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

make 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 make 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 make when another, more precise keyword already carries the block's intent.
• Avoid make 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 make 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_make() -> int {
  make
  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 make is moved, truncated, or combined with the wrong context. Concretely, the explicit value creation does not have the full expected form.

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

Common compilation errors

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

Neighbor keywords

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

Common misreadings

• Reducing make to a local token instead of reading it as part of a full construction.
• Explaining only the syntax and forgetting the reading or diagnostic contract it imposes.

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.

Presence in the book

• docs/book/chapters/05-types.html
• docs/book/chapters/06-procedures.html
• docs/book/chapters/27-grammar.html

See also

• docs/book/chapters/keywords/erreurs-compilateur.html
• docs/book/chapters/keywords/let.html
• docs/book/glossary.html