Keyword and
and is documented here as a full reference entry: grammatical role, semantics, canonical form, valid example, counter-example, diagnostics, interactions, and design notes.
and.Visual anchor: each page now has its own wiki-style profile image. It shows a small code excerpt where and 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
- 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 | and |
| Family | Lexical operator |
| Suggested level | Intermediate |
| Main neighbor | or |
| Short role | and is an operator keyword that changes how values are combined, tested, or traversed. |
| Main effect | and acts at expression level by changing the logical or structural result computed at that exact point. |
The keyword and participates in a relation between values or in the logical reading of an expression. It should not be read in isolation, but as an operator that changes the meaning of the whole expression.
A useful encyclopedic reading should answer three questions: where can and appear, what does it change in the block contract, and how does the compiler signal misuse?
Definition
and is an operator keyword that changes how values are combined, tested, or traversed.
The keyword and participates in a relation between values or in the logical reading of an expression. It should not be read in isolation, but as an operator that changes the meaning of the whole expression.
Grammatical role
Combines two logical expressions by requiring joint validity.
This grammatical role is essential: if a reader understands the structural place of and, they already understand much of the diagnostics that will appear when it is moved or truncated.
Canonical syntax
Canonical form: `left and right`.
The canonical form matters because it gives the compiler and the reader the same reference structure. A large share of diagnostics related to and come from an abbreviated, displaced, or incomplete form.
Detailed semantics
Semantically, and only makes sense with its operands and the surrounding form. The full expression must be read to understand the logical or structural contract it imposes.
In an encyclopedic reading, and 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
and acts at expression level by changing the logical or structural result computed at that exact point.
In other words, the presence of and 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
- `left and right`.
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 both(a: bool, b: bool) -> bool {
give a and b
}
This example shows and 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
and, not the isolated word. - Then identify which contract becomes visible because of
and: type, branch, binding, module, exit, or advanced boundary. - Finish by checking the observable effect produced by the construction that contains
and. - For an operator keyword, reread the full expression to avoid an overly local interpretation.
This guided reading is intentionally closer to a reference page than to a tutorial: it helps reconstruct the exact role of and in a complete block.
Comparison with C
/* C comparison: this role is usually expressed with operators or explicit loops and conditionals. */
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
and 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
andmakes the block contract more explicit at first reading. - When it reduces the number of implicit assumptions the reader must reconstruct mentally.
- When a logical or structural relation must be read as an integral part of the expression.
When to avoid it
- Avoid
andwhen another, more precise keyword already carries the block's intent. - Avoid
andwhen 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
andin 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_and() -> int {
give and
}
The operator surface is incomplete because it is missing the operands or the valid surrounding construct.
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 and is moved, truncated, or combined with the wrong context. Concretely, the logical operator does not have all the operands it needs.
A good encyclopedic counter-example does not show arbitrarily broken code: it isolates the precise reason why and 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 and | 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 and fails, the problem usually comes from an invalid grammatical form, an incoherent type contract, or an incomplete construction.
Neighbor keywords
| Keyword | Operational difference |
|---|---|
or | Direct neighboring keyword: it helps explain what and does, either by contrast or by complement. |
Comparison with neighboring keywords is essential on a wiki-style page: and is better understood when one knows precisely what it does not do.
Common misreadings
- Reducing
andto 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
- The most useful diagnostics signal missing operands, an incompatible value category, or a reading ambiguity.
- In the front-end, these keywords influence expression hierarchy and sometimes precedence rules.