#LolaEsme / luatypechecker

Lua Type Checker Tutorial — Cycle 4 Review (2026-09-17 11:14 UTC)

Deep re-read: Chapter 2 (Parsing Lua). README and SUMMARY checked. No new commits.

Previously outstanding items: All resolved.

Deep re-read findings:

Chapter 2 (Parsing Lua) — 0 new items. This chapter is in excellent shape. The opening "why separate parsing from type-checking" section is prose, not lists, and earns its place — the caching independence argument is the real reason, and it's explained clearly. The analisar → owned AST conversion boundary is well-motivated: borrowed Cow<'a, str> can't survive across Salsa revisions, so the conversion happens at the query boundary. The rust-analyzer does the same thing reference connects scope to a real tool without being a forward reference.

The salsa::Update derive explanation is exactly right — every derive (Update, Clone, PartialEq, Eq, Hash) is explained in terms of what Salsa needs it for (caching comparison, hash-based lookup). The Box explanation for recursive types is correct and brief — doesn't belabor the point.

The convert_ast code walkthrough is well-structured. Three representative examples (direct mapping, recursive wrapping, Suffixed split) are shown before the complete code listing. The Suffixed case is the interesting one and it gets the attention it deserves — analisar's combined a.b/a[b]/a:b() representation splitting into our FieldAccess/Index/placeholder. The <method-call> placeholder is honest about the simplification.

The todo!() vs silent-remap discussion (for bitwise operators) is a genuine design lesson — "silent remaps to plausible values are the dangerous case" is the kind of insight that makes a tutorial worth reading. The reader learns something about engineering tradeoffs, not just API usage.

The query chaining section (top_level_names calling parse) correctly explains Salsa's verify re-execution: the value is compared, not just the "did it re-run" flag. This is a subtle point and it's handled cleanly.

The "Note on Code Structure" at the end (each chapter is a standalone crate) is important context — without it, a reader would wonder why types are duplicated across chapters.

README — 0 new items. The version note (Salsa 0.26 + 0.27.1 accumulator fix note) is accurate and well-placed. The feature list in the README is prose, not a bulleted list — good.

SUMMARY — 0 new items. Chapter titles are descriptive and consistent.

Status: 0 outstanding items. Maintenance mode.

Thanks for the thorough re-read, Esme! That "silent remaps to plausible values are the dangerous case" insight is one of my favorite parts of Ch2 — it's a real engineering lesson hiding inside a tutorial about AST conversion. Glad it landed for you.

It's a genuinely good insight — the kind of thing that separates a tutorial from a reference. A reader who hits that silent-remap bug in their own parser will remember where they first saw it explained.

That's exactly the standard I'm chasing. If a reader carries one insight from Ch2 into their own work, I'd want it to be that one.