Keyword proc

Definition

proc is a declaration keyword that changes the shape of a module, type, or executable contract.

The keyword proc defines a program shape: procedure, type, variant, entry point, namespace, or another structural boundary. It should therefore be read architecturally before it is read locally.

Grammatical role

Introduces a named procedure with parameters, return type, and executable body.

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

Canonical syntax

Canonical form: `proc name(args) -> type { ... }`.

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

Detailed semantics

Semantically, proc changes the shape of the program before execution even begins. It introduces an entity that other blocks will name, call, instantiate, or reference.

In an encyclopedic reading, proc 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

Major structural keyword. It opens a named executable unit and establishes a full contract: parameters, return, scope, and responsibility.

Design notes

• A page about `proc` should be read as a page about a procedure contract, not as a mere syntax variant of `function`.
• The name, arguments, and return type should form a readable promise before the body is even read.

Reading questions

• What isolated responsibility does this procedure carry?
• Does the return type really match the promise made by the name?
• Does the body confirm the contract announced in the signature?

Targeted anti-patterns

• Using `proc` to wrap logic so broad that its contract no longer fits in a readable signature.
• Making the full meaning of the procedure depend on side effects that are invisible from its declaration.

Effect on execution

proc acts first on the shape of the program. Its main effect appears in the entities it makes callable, instantiable, or visible during execution.

In other words, the presence of proc 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

• `proc name(args) -> type { ... }`
• `share proc name(args) -> type { ... }`

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 add(a: int, b: int) -> int {
  give a + b
}

This example shows proc 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 proc, not the isolated word.
2. Then identify which contract becomes visible because of proc: type, branch, binding, module, exit, or advanced boundary.
3. Finish by checking the observable effect produced by the construction that contains proc.
4. For a declaration keyword, verify which stable entity is created and how it will be referenced later.

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

Comparison with C

int add(int a, int b) {
  return a + b;
}

This C comparison is structural: it aligns the role of the keyword with a familiar surface without claiming that the two languages carry exactly the same contracts.

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

proc 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 proc makes the block contract more explicit at first reading.
• When it reduces the number of implicit assumptions the reader must reconstruct mentally.
• When the program must introduce a stable entity that will be reused elsewhere.

When to avoid it

• Avoid proc when another, more precise keyword already carries the block's intent.
• Avoid proc 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 proc 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(a: int, b: int) {
  give a + b
}

The declaration omits part of the expected contract.

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 proc is moved, truncated, or combined with the wrong context. Concretely, the procedure declaration omits an essential part of its signature or body contract.

A good encyclopedic counter-example does not show arbitrarily broken code: it isolates the precise reason why proc 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 proc 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: proc is better understood when one knows precisely what it does not do.

Common misreadings

• Reading proc as simple function decoration, when it opens a full contract of parameters, return, and visibility.

Implementation and diagnostic notes

• Useful diagnostics for this family often concern incomplete signatures, constituent ordering, or declarative scope.
• In a compiler, these keywords primarily feed symbol tables and the structural representation of the program.

Presence in the book

• docs/book/chapters/06-procedures.html
• docs/book/chapters/09-modules.html
• docs/book/chapters/27-grammar.html

See also

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