{
  "version": "v1",
  "pages": [
    {
      "title": "STYLE",
      "path": "book/STYLE.html",
      "content": "STYLE Skip to content Vitte Welcome Documentation Download Source Community News Diagnostics Suggestions Editorial Style Guide (Vitte Book) Book Summary Checklist Glossary This guide is the editorial contract for the whole book. Its purpose is simple: every chapter must teach one coherent thing with one coherent example, without repetitive filler and without line-by-line paraphrase. Core Rules One chapter, one main problem, one main example. Explain the whole flow before explaining local syntax. Do not write line-by-line commentary unless the chapter is explicitly about parsing or debugging a single statement. Every technical chapter must include a nominal path, an invalid path, and an observable result. Every keyword page must show the keyword in Vitte and compare it briefly to C when that comparison clarifies intent. Chapter Contract Concrete Problem : name the real engineering problem. Red Thread (Single Project) : keep one scenario from start to finish. For what : say what this chapter helps the reader build, debug, or decide. What you are going to do : explain the proof path of the chapter. Coherent example : one complete program or subsystem extract. Global explanation : explain responsibilities, data flow, boundaries, and failure points. Invalid case : show how the chapter fails and how the reader notices it. Short exercise : ask for one modification that preserves the chapter invariant. Keyword Contract Definition : state what the keyword means in the language. Syntax : show the canonical shape. Example in Vitte : complete, runnable or near-runnable snippet. Example in C : short comparison when it clarifies semantics. Invalid example : show the misuse and the expected family of diagnosis. Global explanation : explain what the keyword changes in the full flow. Anti-Repetition Rules Do not repeat generic filler such as “read the core idea first”. Do not duplicate the same pitfall list across unrelated chapters. Do not rename the same section three ways; keep one stable heading. Do not comment each line if the reader really needs the architecture of the block. Stdlib Policy The stdlib must be documented by family, not by isolated minimal snippets only. Each family must explain its responsibility, main submodules, integration boundaries, and realistic usage. Examples should be complete enough to show where data enters, which library layer acts, and what comes out. Length And Density Prefer dense examples over decorative prose. Keep bullets for inventories and contracts, not for replacing explanation. If a chapter grows, add more evidence and scenarios, not more filler. Paths And Links Reference the book with the docs/book/ prefix when discussing repository paths. Prefer stable repository-relative paths and stable chapter numbering. book/STYLE.html Back to home",
      "lang": "en",
      "section": "book"
    },
    {
      "title": "Book Health Report",
      "path": "book/book-health.html",
      "content": "Book Health Report table { border-collapse: collapse; width: 100%; } th, td { border: 1px solid #ccc; padding: 8px; text-align: left; } th { cursor: pointer; background-color: #f2f2f2; } Book Health Report Average Score: 0.0 / 100 Total Chapters: 0 Title Score Examples FAQ Tables",
      "lang": "en",
      "section": "book"
    },
    {
      "title": "Editorial Proofreading Checklist",
      "path": "book/checklist.html",
      "content": "Editorial Proofreading Checklist Skip to content Vitte Welcome Documentation Download Source Community News Diagnostics Suggestions Editorial Proofreading Checklist Book Summary Style Glossary Use this list before validating a chapter. Vocabulary consistency: the same concepts have the same names. Punctuation: neatly finished sentences and lists. Numerical examples: at least one limiting case and one nominal case. Invariants: security/validity rules are explicit. Readability: Each block of code has a clear intent. Quick check: the chapter answers \"what happens if the input is invalid?\". Exercise: a À faire is present with a minimal answer key. book/checklist.html Back to home",
      "lang": "en",
      "section": "book"
    },
    {
      "title": "CI rapide (local)",
      "path": "book/ci.html",
      "content": "CI rapide (local) Skip to content Vitte Welcome Documentation Download Source Community News Diagnostics Suggestions Fast CI (local) This project uses make ci-strict as a local full pass: grammar alignment ( grammar-check ), Strict QA docs ( book-qa-strict ), lint stdlib conventions ( package-layout-lint ), lint imports legacy ( legacy-import-path-lint ), negative tests ( negative-tests ), diagnostic snapshots ( diag-snapshots ). One-line order OPENSSL_DIR=/opt/homebrew/opt/openssl@3 CURL_DIR=/opt/homebrew/opt/curl make ci-strict Variant with session export export OPENSSL_DIR=/opt/homebrew/opt/openssl@3 export CURL_DIR=/opt/homebrew/opt/curl make ci-strict Quick dependency check test -d /opt/homebrew/opt/openssl@3 && echo "openssl ok" test -d /opt/homebrew/opt/curl && echo "curl ok" book/ci.html Back to home",
      "lang": "en",
      "section": "book"
    },
    {
      "title": "Classic mistakes",
      "path": "book/classic-mistakes.html",
      "content": "Classic mistakes Skip to content Vitte Welcome Documentation Download Source Community News Diagnostics Suggestions Classic mistakes This page centralizes recurring errors observed in the chapters. Forgetting a guard before a risky operation. Mix business logic and technical projection. Leave implicit states unmodeled. Duplicate a rule instead of centralizing it. Optimize before you have locked in the expected behavior. Recommended use: before validating a chapter, check this list alongside the editorial checklist. book/classic-mistakes.html Back to home",
      "lang": "en",
      "section": "book"
    },
    {
      "title": "CLI Vitte",
      "path": "book/cli.html",
      "content": "CLI Vitte Skip to content Vitte Welcome Documentation Download Source Community News Diagnostics Suggestions CLI Vitte Use : vitte [command] [options] <input> Commands (recommended): help Show help and common tasks init [dir] Create a minimal project skeleton explain <code> Explain a diagnosis (e.g. E0001 ) doctor Check toolchain prerequisites parse Parser only (without backend) check Parse + resolve + IR (without backend) emit Only emit Vitte (without compilation) build Complete build (default) profile Complete construction with summary of times/memory per step reduce Reduce a failed file to a minimal reproducer clean-cache Delete stage cache files .vitte-cache mod graph Display the import graph, cycles and module weights (LOC/exports/imports) mod doctor Check the hygiene of imports (unused, aliases, canonical paths, collisions) mod contract-diff Compare the exported contract of a module between 2 entries ( --old / --new ) Options: --lang <code> Language of diagnostics (e.g. en , fr ). By default LANG/LC_ALL , then en . --explain <code> Explain a diagnosis (e.g. E0001 ). --stage <name> Stop at parse|resolve|ir|backend . --diag-json Issue diagnostics in JSON. --diag-json-pretty Issue readable JSON diagnostics (includes diag_schema ). --diag-code-only Issue compact diagnostics ( file:line:col CODE ), useful for CI. --deterministic Stable output order for diagnostics and tools. --cache-report Show cache hit/miss ratio parse/resolve/ir. --runtime-profile <name> Restrict runtime/stdlib imports: core|system|desktop|arduino . --allow-experimental Allow imports from modules experimental/... . --warn-experimental Degrade an experimental import refusal to a warning (migration mode). --deny-internal Enforce confidentiality of internal modules (default behavior). --allow-internal Disable internal module privacy checking. --strict-modules Prohibit glob imports and impose a strict form of module imports. --dump-stdlib-map Show resolved map stdlib module -> exported symbols (history option name). --dump-module-index Export the full JSON of the module index ( modules , imports , exports , loc ). --json For mod graph : emit the JSON payload of the graph. --from <module> For mod graph : limit the view to the subgraph reachable from the module. --dump-ast Export the AST after parsing. --dump-ir Export IR ( --dump-mir as alias). --strict-types Reject compatibility aliases ( integer , uint32 , etc.) and enforce canonical names. --strict-imports Require explicit import aliases, reject unused aliases, and disallow relative paths. --fix For mod doctor : Show concrete rewrite suggestions. --max-imports <N> For mod doctor : report modules whose fan-out exceeds N . --old <file> / --new <file> For mod contract-diff . --strict-bridge Alias ​​of --strict-imports for the binding policy. --fail-on-warning Treat warnings as errors. --stdout Output Vitte to standard output (implies emit ). --emit-vitte Emit a Vitte artifact only. --repro Enable reproducible output. --repro-strict Impose a strictly deterministic order for IR lowering. --parse-modules Parse + load modules (without resolution/lowering). --parse-silent Delete parse-only mode information logs. Diagnostics include stable error codes (e.g. error[E0001]: ... ). Examples: vitte help vitte init vitte init app vitte explain E0001 vitte doctor vitte parse --lang=fr src/main.vit Error codes: Diagnostics use stable prefixes per layer: E000x : parse/grammar E100x : resolution E1007 : invalid signed/unsigned cast E1010..E1020 : module/stdlib import contract E200x : IR/lowering E300x : backend/toolchain Codes are defined in src/compiler/frontend/diagnostics_messages.vitl . .ftl localization files can translate by code (preferred) or by message key. Stdlib: See docs/book/stdlib.html for stdlib modules and examples. Contract and ABI surface: docs/book/compiler-stdlib-contract.html , docs/book/stdlib_abi_surface_v1.txt . Historical options (still supported): mod api-diff (aka mod contract-diff ) --stdlib-profile (historical alias of --runtime-profile ) correspondence: minimal->core , kernel->system , full->desktop --parse-only --resolve-only --hir-only --mir-only --emit-vitte --strict-parse Notes: The commands set a default mode, but explicit options take precedence. For strict analysis, use parse --strict-parse <file> . For the JSON of the graph in CI: vitte mod graph --json --from __root__ <file> . book/cli.html Back to home",
      "lang": "en",
      "section": "book"
    },
    {
      "title": "Compiler Contract <-> Stdlib",
      "path": "book/compiler-stdlib-contract.html",
      "content": "Compiler Contract <-> Stdlib Skip to content Vitte Welcome Documentation Download Source Community News Diagnostics Suggestions Compiler contract stdlib This document defines the stable contract between the Vitte compiler and the stdlib runtime surface. Terminology used in the doc and CLI: “Vitte binding surface” replaces “libc surface”. “Vitte binding” replaces “interop C”. 1. Source of truth Versioned ABI surface file: stdlib_abi_surface_v1.txt (historical name). Next ABI version: stdlib_abi_surface_v2.txt (historical name). Source root of the stdlib: dedicated source tree. Runtime ABI header: src/compiler/backends/runtime/vitte_runtime.vitl . 2. Stable stdlib profiles --runtime-profile controls which stdlib modules are allowed. --stdlib-profile is kept as a historical alias. core (history minimal ): only core/** . desktop (history full ): all stdlib modules. system (history kernel ): core/** + kernel/** . arduino : core/** + arduino/** . If an import is not authorized, the compiler emits E1010 . If a stdlib module is missing, the compiler emits E1014 . Module levels: public : stable import surface. internal : private namespace ( */internal/* ), blocked without owner ( E1016 ). experimental : activation only with --allow-experimental ( E1015 ). 3. Strictness of imports --strict-imports (aka --strict-bridge ) imposes import hygiene: explicit alias required on use / pull ( E1011 ). explicit aliases must be used ( E1012 ). non-canonical relative paths are rejected ( E1013 ). 4. Runtime/Vitte link error boundary Parse layer: E000x . Resolve layer: E100x (includes stdlib/import constraints). IR layer: E200x . Backend layer/toolchain: E300x . 5. Tools Export stdlib symbol map: vitte check --dump-stdlib-map <file.vit> Export the full module index: vitte check --dump-module-index <file.vit> Graph and doctor: vitte mod graph <file.vit> vitte mod doctor <file.vit> Check surface ABI against stdlib source: tools/lint_stdlib_api.py ABI compatibility issue: tools/check_stdlib_abi_compat.py Profile Snapshots: tools/stdlib_profile_snapshots.sh 6. Binding surface name For documentation and examples of system/Vitte binding, prefer stdlib-oriented names: print read path env bytes alloc process Bridge module plan in the doc: bridge/io bridge/memory bridge/system bridge/time bridge/net book/compiler-stdlib-contract.html Back to home",
      "lang": "en",
      "section": "book"
    },
    {
      "title": "Vitte Errors",
      "path": "book/errors.html",
      "content": "Vitte Errors Skip to content Vitte Welcome Documentation Download Source Community News Diagnostics Suggestions Vitte Errors This page is the stable reference for common diagnostics and fixes. Layer map: parse : syntax and structure checks. resolve : name, type, import and declaration checks. IR : lowering and intermediate representation checks. backend : Code generation and toolchain checks. Each diagnosis follows the same structure: Code Symptom Probable cause Correction Example See also ## E0001 - expected identifier Code: E0001 Layer: parse Symptom: The parser was expecting a variable, type, module, or declaration name. Probable cause: a declaration is missing its identifier, or the token after a keyword is not a valid name. Fix: Add a valid identifier where the parser indicates. Example: proc main() -> i32 { return 0 } See also: book/poche/07-reading-errors.html , book/cli.html ## E0002 - expected expression Code: E0002 Layer: parse Symptom: The parser was expecting an expression at this location. Probable cause: A value, call, or block expression is missing after a keyword or operator. Fix: provide an expression like 1 , name , call() or { ... } . Example: let x = 1 See also: book/poche/07-reading-errors.html , book/cli.html ## E0003 - expected pattern Code: E0003 Layer: parse Symptom: The parser was expecting a pattern. Probable cause: A construct when or similar to match received an incomplete pattern. Fix: use a pattern as an identifier or constructor, for example Some(x) . Example: when x is Option.Some { return 0 } See also: book/poche/07-reading-errors.html , book/cli.html ## E0004 - expected type Code: E0004 Layer: parse Symptom: The parser was expecting a type name. Probable cause: A type annotation is present, but the right member is missing or malformed. Fix: Use a built-in type or a named type, for example int or Option[T] . Example: proc id(x: int) -> int { return x } See also: book/poche/07-reading-errors.html , book/cli.html ## E0005 - `end` expected Code: E0005 Layer: parse Symptom: A block was opened but not closed with end or .end . Probable cause: a proc , form or pick block is missing its terminator. Fix: Add missing terminator for open construct. Example: form Point field x as int .end See also: book/poche/07-reading-errors.html , book/cli.html ## E0006 - `proc` expected after attribute Code: E0006 Layer: parse Symptom: An attribute must be followed by an proc declaration. Probable cause: the attribute is hooked to the wrong element or is alone. Fix: Place the attribute directly above a proc . Example: #[inline] proc add(a: int, b: int) -> int { return a + b } See also: book/poche/07-reading-errors.html , book/cli.html ## E0007 - top-level declaration expected Code: E0007 Layer: parse Symptom: The parser was expecting a top-level declaration. Probable cause: An element appears at the root of the file, but it is not one of the supported declarations. Correction: limit the top-level to space , use , form , pick , type , const , proc and entry . Example: space my/app proc main() -> int { return 0 } See also: book/poche/07-reading-errors.html , book/cli.html ## E0008 - duplicate pattern binding Code: E0008 Layer: parse Symptom: A pattern has linked the same name more than once. Probable cause: The pattern reuses a binding in two places. Fix: give a separate name to each binding. Example: when Pair(x, x) { return 0 } See also: book/poche/07-reading-errors.html , book/cli.html ## E0009 - unknown type Code: E0009 Layer: resolve Symptom: A referenced type name was not found. Probable cause: Type is misspelled or not imported. Fix: check spelling or import type with use or pull . Example: use std/core/option.Option proc f(x: Option[int]) -> int { return 0 } See also: book/compiler-stdlib-contract.html , book/cli.html ## E0010 - unknown generic base type Code: E0010 Layer: resolve Symptom: The base type of a generic was not found. Probable cause: Generic base type is misspelled or not imported. Fix: check spelling or import base type with use or pull . Example: use std/core/option.Option let x: Option[int] = Option.None See also: book/compiler-stdlib-contract.html , book/cli.html ## E0011 - a generic type requires at least one argument Code: E0011 Layer: resolve Symptom: A generic type was written without a type argument. Probable cause: Type application is incomplete. Fix: provide one or more type arguments between [ ] . Example: let x: Option = Option.None See also: book/compiler-stdlib-contract.html , book/cli.html ## E0012 - unsupported type Code: E0012 Layer: resolve Symptom: This type form is not yet supported. Probable cause: The type syntax is valid enough to be parsed, but the compiler does not yet accept this form. Fix: Use a supported type form like built-in types, named types, pointers, slices or proc types. Example: let p: *int = &value See also: book/compiler-stdlib-contract.html , book/cli.html ## E0013 - unknown identifier Code: E0013 Layer: resolve Symptom",
      "lang": "en",
      "section": "book"
    },
    {
      "title": "Vitte Glossary",
      "path": "book/glossary.html",
      "content": "Vitte Glossary Skip to content Vitte Welcome Documentation Download Source Community News Diagnostics Suggestions Glossary Vitte Book Summary Technical index Checklist This glossary centralizes the basic concepts to avoid redefining them in each chapter. int : type of signed integers, used for calculations without decimal places. string : text type. bool : logical type ( true or false ). proc : declaration of a procedure with inputs and output type. entry : executable entry point of the program. let : creation of a local variable. set : update of an existing variable. if : conditional custody. match : branch selection according to a value form. case : branch of a match . otherwise : backup branch of a match . give : immediate return from a branch. return : End of execution with an exit code. form : Named data structure. pick : closed variant type. Reading Tip: If you are stuck on a keyword during a chapter, come back here, then return to the example immediately. book/glossary.html Back to home",
      "lang": "en",
      "section": "book"
    },
    {
      "title": "Book Home",
      "path": "book/index.html",
      "content": "Book Home Skip to content Vitte Welcome Documentation Download Source Community News Diagnostics Suggestions Book Home New beginner entry point: docs/book/poche/summary.html (all-in-pocket format). This book is organized into three complementary layers. The chapters carry the full conceptual progression. The logic section isolates execution mechanisms and code traces. The keywords section documents each lexical element of the language with short examples. Main entry point: docs/book/summary.html . Recommended route if the book feels too dense: docs/book/poche/summary.html . Quick technical entry point: docs/book/technical-index.html . Editorial style guide: docs/book/STYLE.html . Summary Pocket Chapters Glossary Checklist Where to Learn What Getting started and basics: docs/book/chapters/00-foreword.html , docs/book/chapters/01-starting.html , docs/book/chapters/04-syntax.html . Types and data: docs/book/chapters/05-types.html , docs/book/chapters/08-structures.html , docs/book/chapters/11-collections.html . Control and logic: docs/book/chapters/06-procedures.html , docs/book/chapters/07-control.html , docs/book/logique/index.html . Modules and architecture: docs/book/chapters/09-modules.html , docs/book/chapters/15-pipeline.html , docs/book/chapters/20a-overall-architecture.html . Quality and execution: docs/book/chapters/10-diagnostics.html , docs/book/chapters/18-tests.html , docs/book/chapters/20-reproducibility.html . Full projects: docs/book/chapters/21-cli-project.html to docs/book/chapters/26-editor-project.html . Editorial Charter Style: precise, educational, concrete, execution-oriented. Detail level: explain the intent, guard, exit, and state effect. Required frame: Goal -> Example -> Why it matters -> Mental check -> Try this -> Minimal fix . Target length: see the detailed thresholds in docs/book/STYLE.html . Anti-repetition rule: do not redefine the basics ( int , proc , etc.) outside the opening and glossary. book/index.html Back to home",
      "lang": "en",
      "section": "book"
    },
    {
      "title": "Pedagogical Roadmap",
      "path": "book/roadmap-pedagogique.html",
      "content": "Pedagogical Roadmap Skip to content Pedagogical Roadmap Upcoming simplifications: novice mode tuning, chapter quality review, diagnostics examples, project tracks.",
      "lang": "en",
      "section": "book"
    },
    {
      "title": "Start in 30 minutes",
      "path": "book/start-30-min.html",
      "content": "Start in 30 minutes Skip to content Start in 30 minutes How to read First program Conditions and loops",
      "lang": "en",
      "section": "book"
    },
    {
      "title": "Book Status",
      "path": "book/status.html",
      "content": "Book Status Skip to content Book Status Coverage, completeness, and checks are generated from chapters metadata. loading…",
      "lang": "en",
      "section": "book"
    },
    {
      "title": "Stdlib (Selection)",
      "path": "book/stdlib.html",
      "content": "Stdlib (Selection) Skip to content Vitte Welcome Documentation Download Source Community News Diagnostics Suggestions Stdlib (Selection) This page is a library map, not a minimal snippet dump. The goal is to show the main families, the responsibilities they own, and the kinds of complete programs they support. Complete Reference Atlas The stdlib now has a wiki-style reference corpus aligned with the actual src/vitte/stdlib tree: one page per family, one page per file, and one SVG portrait per module in the same spirit as the keyword pages. book/stdlib-reference/index.html for the full atlas. book/stdlib-reference/modules/ for the file-by-file directory. book/compiler-stdlib-contract.html for the compiler/runtime contract. Library Families Core : types, strings, memory helpers, panic/runtime-adjacent basics, low-level algorithms. Collections : vector, deque, queue, stack, linked list, hashmap, hashset, graph, matrix. Data : dataset, schema, transform, merge, cleaning, statistics. Json and encoding : parse, builder, stringify, serialize, schema, utf, url, base64, hex, html. Path and io : manipulation, walkers, special locations, globbing, file, buffer, stream, stdio. Math : arithmetic, algebra, logic, geometry, trigonometry, probability, statistics, modular, matrix, vector. Crypto and compression : hashes, HMAC, random, symmetric/asymmetric primitives, huffman, lz, deflate, brotli. Async and threading : future, executor, channel, thread, mutex, threadpool. Kernel and ffi : process, scheduler, users, signals, device, memory, network, ABI-facing integration. Complete Example space demo/report form Report { name: string root: string status: int } pick Outcome { case Ok(summary: string) case Err(code: int) } proc normalize_root(root: string) -> string { if root == \"\" { give \".\" } give root } proc validate_report(r: Report) -> Outcome { if r.name == \"\" { give Outcome.Err(11) } if r.status < 0 { give Outcome.Err(12) } give Outcome.Ok(r.name) } proc render_report(r: Report) -> string { let normalized: string = normalize_root(r.root) give \"{name=\" + r.name + \",root=\" + normalized + \",status=ok}\" } entry main at core/app { let r: Report = Report(\"demo\", \"src/vitte/compiler\", 0) return 0 } This single example is enough to show where future stdlib families plug in: path for root normalization, json for serialization, io for file emission, collections for grouping reports, and async if generation becomes concurrent. How To Read The Catalog Start from the responsibility of the code, not from the module name you happen to remember. Prefer pure families first: core , strings , collections , data . Move to host-facing families only when the problem genuinely touches files, processes, or runtime coordination. Keep bridge/kernel/ffi boundaries explicit because they carry the highest coupling cost. book/stdlib.html Back to home",
      "lang": "en",
      "section": "book"
    },
    {
      "title": "Summary",
      "path": "book/summary.html",
      "content": "Summary Skip to content Vitte Welcome Documentation Download Source Community News Diagnostics Suggestions Summary Book Pocket Summary Technical Index Glossary Checklist Pocket Book Pocket Summary Vitte Glossary Editorial Style Guide Editorial Proofreading Checklist Classic Mistakes Projects: CLI (21) -> HTTP (22) -> System (23) -> KV (24) -> Arduino (25) -> Editor (26) Vitte Technical Index Surface grammar (EBNF) Foreword (reading method) Preface (learning trajectory) 1. Get started with Vitte 2. Philosophy of language 3. Structure of a project 4. Essential Syntax 5. Types and values 6. Procedures and contracts 7. Control Instructions 8. Data Structures 9. Modules and organization 10. Diagnostics and errors 11. Collections and iteration 12. Pointers, references and memory 13. Generics 14. Macros 15. Compiler Pipeline 16. Interop and ABI 16a. Vitte Binding with std/bridge 17. Stdlib 17a. stdlib migration plan 18. Testing and validation 19. Performance 20. Reproducibility 20a. Overall Language Architecture 21. CLI Project 22. HTTP Project 23. System Project 24. KV Project 25. Arduino Project 26. Editor Project 27. Grammar Reference 27.1 Language overview 27.2 Glossary and tokens (spaces, comments, identifiers, keywords) 27.3 Literals (numbers, strings, booleans, lists, etc.) 27.4 Expressions (priority, associativity, parentheses) 27.5 Basic instructions (blocks, assignment, expression statements) 27.6 Flow control ( if , loop , for , select/when , match ) 27.7 Functions and scope ( proc , parameters, closures) 27.8 Types and annotations 27.9 Data structures (shapes, picks/cases, lists, slices, pointers) 27.10 Modules and imports ( space , pull , use , share ) 27.11 Diagnostics and error management (lexical/syntactic) 27.12 Formal grammar in EBNF (complete rules) 27.13 Ambiguities and resolution (precedence, LL/LR conflicts, else ) 27.14 AST and grammar mapping -> parser 27.15 Complete commented examples 27.16 Appendices (cheat sheets, conventions, grammar tests) 28. Code conventions 29. Architecture style 30. FAQs 31. Build errors 32. Vitte Module Catalog 33. Suggested Chapters 34. Compiler Mental Model 35. Anatomy of an Error Message 36. Naming Strategies 37. Large-Scale Module Conventions 38. Type-Driven Refactoring 39. Design of stable public APIs 40. Compatibility Management 41. Versioning and Migration 42. Robust Procedure Patterns 43. Common Anti-Patterns in Vitte Code 44. Performance: Measure Before Optimizing 45. Performance: allocations and copies 46. ​​Performance: adapted data structures 47. Repeatable Debugging 48. Tracing and observability 49. Writing Readable Unit Tests 50. Scenario-Oriented Integration Testing 51. Compiler non-regression tests 52. Grammar tests (valid/invalid corpus) 53. Property-based testing for the parser 54. Fuzzing the source input 55. Memory security and invariants 56. Defensive input/output programming 57. Semantic error handling 58. CI pipeline for a Vitte project 59. Risk-oriented code review 60. Sustainable technical documentation 61. Generation of Grammar Diagrams 62. Advanced EBNF Reading of Language 63. Resolution of Syntactic Ambiguities 64. Mapping AST -> IR (practical view) 65. ABI and Vitte interop contracts 66. Macros: use cases and limits 67. Generics: design and compromise 68. Hexagonal architecture in Vitte 69. Complete CLI production-ready project 70. HTTP production-ready complete project 71. Complete project system service 72. Embedded project (memory/time constraints) 73. Team skills development plan 74. Document the documentation Logical elements of Vitte Logic - Conditions Logic - Loops Logic - Matching Logic - Expressions Logic - Types and Contracts Vitte Keywords Keyword coverage Browse keywords Commented keyword gallery Keywords Learning Packs Unused keywords Glossary of compiler errors Keyword entry Keyword proc Keyword let Keyword make Keyword set Keyword type Keyword form Keyword trait Keyword field Keyword pick Keyword case Keyword if Keyword else Keyword otherwise Keyword loop Keyword for Keyword in Keyword break Keyword continue Keyword select Keyword when Keyword match Keyword is Keyword give Keyword emit Keyword asm Keyword unsafe Keyword return Keyword use Keyword space Keyword pull Keyword share Keyword const Keyword macro Keyword as Keyword at Keyword and Keyword or Keyword not Keyword all Keyword bool Keyword string Keyword int Keyword true Keyword false book/summary.html Back to home",
      "lang": "en",
      "section": "book"
    },
    {
      "title": "Vitte Technical Index",
      "path": "book/technical-index.html",
      "content": "Vitte Technical Index Skip to content Vitte Welcome Documentation Download Source Community News Diagnostics Suggestions Vitte Technical Index Summary Book Pocket Summary Glossary Checklist This index links language mechanisms, narrative chapters, logical pages and keyword pages so you can find a concept by technical intent. Entry points and orchestration: see docs/book/chapters/01-starting.html , docs/book/chapters/04-syntax.html , docs/book/chapters/keywords/entry.html , docs/book/chapters/keywords/at.html . Procedures and contracts: see docs/book/chapters/06-procedures.html , docs/book/logique/types-et-contrats.html , docs/book/chapters/keywords/proc.html , docs/book/chapters/keywords/give.html , docs/book/chapters/keywords/return.html . Types and data modeling: see docs/book/chapters/05-types.html , docs/book/chapters/08-structures.html , docs/book/chapters/keywords/form.html , docs/book/chapters/keywords/pick.html , docs/book/chapters/keywords/case.html , docs/book/chapters/keywords/type.html . Conditions and guards: see docs/book/logique/conditions.html , docs/book/chapters/07-control.html , docs/book/chapters/keywords/if.html , docs/book/chapters/keywords/else.html , docs/book/chapters/keywords/otherwise.html , docs/book/chapters/keywords/and.html , docs/book/chapters/keywords/or.html , docs/book/chapters/keywords/not.html . Loops and iteration: see docs/book/logique/boucles.html , docs/book/chapters/11-collections.html , docs/book/chapters/keywords/loop.html , docs/book/chapters/keywords/for.html , docs/book/chapters/keywords/in.html , docs/book/chapters/keywords/break.html , docs/book/chapters/keywords/continue.html . Pattern matching and decomposition: see docs/book/logique/matching.html , docs/book/chapters/keywords/match.html , docs/book/chapters/keywords/select.html , docs/book/chapters/keywords/when.html , docs/book/chapters/keywords/is.html . Expressions and conversions: see docs/book/logique/expressions.html , docs/book/chapters/keywords/as.html , docs/book/chapters/keywords/int.html , docs/book/chapters/keywords/bool.html , docs/book/chapters/keywords/string.html . Modules and organization: see docs/book/chapters/03-project.html , docs/book/chapters/09-modules.html , docs/book/chapters/keywords/space.html , docs/book/chapters/keywords/pull.html , docs/book/chapters/keywords/use.html , docs/book/chapters/keywords/share.html . Interop and unsafe boundaries: see docs/book/chapters/12-pointers.html , docs/book/chapters/16-interop.html , docs/book/chapters/keywords/unsafe.html , docs/book/chapters/keywords/asm.html . Quality, tests, and reproducibility: see docs/book/chapters/10-diagnostics.html , docs/book/chapters/18-tests.html , docs/book/chapters/20-reproducibility.html . Performance and architecture: see docs/book/chapters/19-performance.html , docs/book/chapters/29-style.html . book/technical-index.html Back to home",
      "lang": "en",
      "section": "book"
    }
  ]
}