Skip to content

Commit 28af966

Browse files
hyperpolymathclaude
andcommitted
docs(spec): thin SPEC.md §8 to forward-reference codegen-environment.adoc
PR #94 contributes docs/specs/codegen-environment.adoc as the canonical .adoc spec for the codegen module environment. This commit removes the duplicate inline §8.1/§8.2 in SPEC.md and replaces the section body with a 2–3 sentence pointer to the canonical file, keeping the §8 heading as an anchor so existing cross-references still resolve. §2.9 (const_decl EBNF) and §2.10 (extern_*_decl EBNF) are retained — they are grammar productions and belong in SPEC.md. Refs #89 — companion to PR #94 (canonical doc) and PR #92 (extern impl). Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
1 parent fbbc569 commit 28af966

1 file changed

Lines changed: 8 additions & 46 deletions

File tree

docs/specs/SPEC.md

Lines changed: 8 additions & 46 deletions
Original file line numberDiff line numberDiff line change
@@ -543,52 +543,14 @@ Compiles to (ownership removed):
543543

544544
## 8. Codegen Module Environment
545545

546-
This section describes how the WebAssembly code generator (`lib/codegen.ml`)
547-
builds its name environment. It is implementation documentation aimed at
548-
contributors; the language semantics are fully specified in §2–4.
549-
550-
### 8.1 Name Environment (`func_indices`)
551-
552-
The codegen context maintains a single association list
553-
554-
```ocaml
555-
func_indices : (string * int) list
556-
```
557-
558-
that maps every top-level name visible at later declaration sites to an
559-
integer key. Two distinct kinds of binding share this table:
560-
561-
| Source declaration | Key value | Meaning |
562-
|--------------------|-----------|---------|
563-
| `fn f(…) { … }` | `k ≥ 0` | WebAssembly function index (imports + defined functions, combined) |
564-
| `const C: T = e` | `-(g + 1)`, where `g` is the global's index in the Wasm `globals` vector | Negative sentinel reserved for constants |
565-
566-
Sign-based partitioning is deliberate: `k ≥ 0` decodes directly as a Wasm
567-
`funcidx`, and `k < 0` recovers the global index as `g = -(k + 1)`. A
568-
single integer per name keeps the lookup uniform across both kinds of binding.
569-
570-
**Population.** Top-level declarations are visited in source order by
571-
`gen_decl`, which is folded over `prog.prog_decls` from `generate_module`.
572-
The two relevant cases are:
573-
574-
- `TopFn fd` — registers `(fd.fd_name.name, func_idx)` in `func_indices`
575-
*before* generating the function body, so the body may recursively refer
576-
to its own name.
577-
- `TopConst tc` — generates the global initializer, appends the global to
578-
`ctx.globals`, then registers `(tc.tc_name.name, -(global_idx + 1))` in
579-
`func_indices`.
580-
581-
Because population is strictly single-pass and in declaration order,
582-
forward references (to either functions or constants declared later in the
583-
file) are not supported by the current backend.
584-
585-
**Call-site lookup.** The `ExprApp (ExprVar id, _)` branch of `gen_expr`
586-
consults `func_indices` to translate a direct call into a Wasm `call k`
587-
instruction. Decoding the negative sentinel back to a `global.get`
588-
needed to make a bare `const` identifier usable inside another top-level
589-
declaration's body — is tracked as a known gap in issue #73. The encoding
590-
documented in this section is the data layout the fix relies on; the
591-
call-site decode path will land alongside that fix.
546+
The WebAssembly code generator's name environment — the `func_indices`
547+
sign-sentinel encoding for `fn`/`const` bindings, the population order, the
548+
call-site decode path, and (once #92 lands) the treatment of `extern fn` /
549+
`extern type` declarations — is documented in full in
550+
`docs/specs/codegen-environment.adoc`.
551+
552+
That spec is the canonical implementation reference; this section is a thin
553+
anchor preserved so cross-references to "SPEC.md §8" continue to resolve.
592554

593555
## Appendix: Grammar Reference
594556

0 commit comments

Comments
 (0)