Appendix E: Links and references

Every reference cited across the book's own "Further reading" sections, collected here in one place, grouped by kind.

Odin (official)

• Home: https://odin-lang.org/
• Language overview: https://odin-lang.org/docs/overview/
• Unions: https://odin-lang.org/docs/overview/#unions
• The any type: https://odin-lang.org/docs/overview/#any-type
• Structs, the direct model for Chapter 5's own struct: https://odin-lang.org/docs/overview/#structs
• Enumerations, the direct model for Chapter 5's own enum: https://odin-lang.org/docs/overview/#enumerations
• Arrays, the direct model for Chapter 6's fixed-capacity design: https://odin-lang.org/docs/overview/#arrays
• Packages, the direct model for Chapter 20's own qualified, path-based imports: https://odin-lang.org/docs/overview/#packages
• The context system, context.temp_allocator's own arena pattern, the direct model for Chapter 10's per-VM-instance Value_Arena: https://odin-lang.org/docs/overview/#implicit-context-system
• Package documentation: https://pkg.odin-lang.org/
• core:os: https://pkg.odin-lang.org/core/os/ (file I/O, modification_time_by_path, File_Info; Chapter 19's own native live-reload and Chapter 20's own module loader, and the reason muspel/ itself has to stay free of it, Chapter 21)
• core:strconv: https://pkg.odin-lang.org/core/strconv/
• core:mem, Arena/arena_init/arena_allocator: https://pkg.odin-lang.org/core/mem/ (Chapter 10's own Value_Arena, a plain buffer-backed bump allocator with no OS virtual memory, portable to -target:js_wasm32 unlike core:mem/virtual's own arena)

Language implementation

• Crafting Interpreters, Robert Nystrom's freely available book: https://craftinginterpreters.com/, the direct model for this book's own Parts I to IV structure, credited generously and repeatedly throughout. Chapter-specific pages cited along the way:
• Scanning: https://craftinginterpreters.com/scanning.html
• Parsing Expressions: https://craftinginterpreters.com/parsing-expressions.html
• Evaluating Expressions: https://craftinginterpreters.com/evaluating-expressions.html
• Statements and State: https://craftinginterpreters.com/statements-and-state.html
• Resolving and Binding: https://craftinginterpreters.com/resolving-and-binding.html
• Chunks of Bytecode: https://craftinginterpreters.com/chunks-of-bytecode.html
• A Virtual Machine: https://craftinginterpreters.com/a-virtual-machine.html
• Jumping Back and Forth: https://craftinginterpreters.com/jumping-back-and-forth.html
• Calls and Functions: https://craftinginterpreters.com/calls-and-functions.html
• A Bytecode Virtual Machine (the whole part's own overview): https://craftinginterpreters.com/a-bytecode-virtual-machine.html
• Recommended as the next stop for exactly what this book scopes out: full closures, a garbage collector, a from-scratch static type system.
• Pratt parsing (Vaughan Pratt's original technique; precedence climbing, this book's own chosen variant, is a simplified form of it). A short EBNF primer, for readers new to grammar notation: https://en.wikipedia.org/wiki/Extended_Backus%E2%80%93Naur_form
• Wren, a small, embeddable, bytecode-VM scripting language by the same author as Crafting Interpreters: named throughout as a real-world, production-quality example of exactly this book's own category of project.
• Lua's reference manual, the closest mainstream analogue to two of this book's own central mechanisms:
• Coroutines, section 2.6, the closest mainstream analogue to Chapter 15's own suspend/resume mechanism: https://www.lua.org/manual/5.4/manual.html#2.6
• lua_yieldk and the continuation-function mechanism, section 4.7, the authentic prior art for the harder native-call-boundary problem Chapter 15's own native-builtins-never-yield rule avoids by design rather than by machinery: https://www.lua.org/manual/5.4/manual.html#4.7
• The C API generally, section 4, lua_push*/lua_to* and lua_State's own extra-data slot: the closest mainstream analogue to Chapter 16's Value marshalling and VM.user_data respectively: https://www.lua.org/manual/5.4/manual.html#4
• The closure/upvalue design, the "full" version of Muspel's own deliberately simplified closures (section 12.4).
• Tables, section 3.4.9, the closest mainstream analogue to a dynamically-typed language's own answer to structured data, and the contrasting, fully general design Chapter 5's named-fixed- field structs and Chapter 6's fixed-capacity arrays both deliberately decline to copy: https://www.lua.org/manual/5.4/manual.html#3.4.9
• Python's own import cycle-detection behaviour, a contrasting, credited comparison point for Chapter 20's own load-time cycle Gotcha: freely searchable as "Python circular import."
• Roblox's Luau runtime and its own instruction-count-based script budgeting, a production system solving the identical "don't let one script hang the host" problem Chapter 18's own Instruction_Tick_Budget/Instruction_Hard_Cap pair solves at a much smaller scale.
• WebAssembly runtime "fuel"/step-limiting mechanisms (available in several WASM embedding APIs, Wasmtime's among them): the same fuel-metering idea Chapter 18's own instruction count implements, at a different layer of the stack.
• The Debug Adapter Protocol (DAP), the shape a real, editor-integrated debugger's own wire protocol takes in production tools (VS Code's own debugging support is built on it): musc debug's own step/continue/stack-inspect loop is recognisably DAP's core vocabulary, minus the protocol, the wire format, and the editor integration around it (Chapter 14).
• Python generators' own close() method, the comparison point for Chapter 15's own scope cut around preemptive cancellation of a suspended script: https://docs.python.org/3/reference/expressions.html#generator.close
• Unity's own domain-reload feature, the general shape of "edit and continue" in a real, shipping engine, and the specific state-migration alternative Chapter 19's own Design decision named and declined to build.
• Unity's ECS-adjacent pattern and Unreal's compiled-Blueprint-graph-plus-per-instance-state model, named generally (not claimed as a direct source) as real-world engines that split shared compiled logic from per-instance state the same way Chapter 17's own many-VM-instances architecture does.

Primary/other, within the dinn monorepo

• The dinn monorepo's own house style (root CLAUDE.md): TowerDefs-style single-source-of- truth tables (credited throughout, most directly as the model for opcodes.odin's own opcode table and Embers' own Script_Builtins), the JS-handle-table pattern from odindom (vendor/odindom, credited as the direct model for Chapter 16's own host/script value- marshalling boundary and Embers' own entity-handle convention), and the no-per-frame-allocation discipline every fixed-capacity array in this book's own code/ follows.
• yo_odin's own batch renderer and native dev server (server/serve.odin): reused, credited, never re-derived, for Embers' own visuals and its own http://localhost:9000 hosting (Chapter 21).

This book's own companion volumes

• Yo Odin (https://nofuss.co.za/yo_odin/), the shelf's own introductory WASM/canvas volume, building Destroids; this book's own stated prerequisite.
• Odin't Know That (https://nofuss.co.za/odint_know_that/), the shelf's own native-desktop volume, building Sköll with vendor:raylib; an equally valid prerequisite for the Odin comfort this book assumes.