format: define context name as a referenceable identifier (activation correlation)#236
Merged
Merged
Conversation
Reframe the `name` context from a "disambiguation label" to its intended purpose: a machine-generated identifier for a context that other contexts reference by name, unique within a program. State the per-program uniqueness requirement. Apply it to activation reconstruction: an `invoke` context declares an activation's name; the matching `return` and the body's member instructions reference it. This pairs a call with its return order-independently — resolving the two cases push/pop + the inline marker alone cannot: adjacent same-function activations and reordered/interleaved bodies. When present, names are authoritative for activation structure; push/pop + marker-count are the name-less fallback. - name.schema.yaml: rewrite description (purpose + uniqueness); examples. - name.mdx: frame `name` as the referenceable-context-name primitive, then pick-selection and invoke/return correlation as applications; note gather carries distinct co-located names (tailcall). - invoke.mdx: add "Correlating with `name`" to Reconstructing activations (Layer 2 authoritative when present). No schema structure change.
Contributor
|
…eely) Per writer review of #236: 'a name must be unique' misread as 'appears once', but a name deliberately recurs — the invoke declares it, the return and every body instruction reference it. State the requirement on the declaration: each name is declared by exactly one context; other contexts reference it freely. Mirror the wording across name.schema.yaml, name.mdx, and invoke.mdx. Plus prose polish (marker-run phrasing, pick handle).
This was referenced Jul 3, 2026
gnidan
added a commit
that referenced
this pull request
Jul 3, 2026
…e/return/revert, scope `name` to pick (#240) * format: correct activation correlation — `activation` id, scope `name` to pick #236 overloaded the `name` context to also correlate invoke/return, but a sibling `name` inherently *declares* the context it sits in — so a `return` carrying the same `name` would be a second declaration, violating the per-name uniqueness. Correct it with two distinct identifiers for two distinct jobs (gnidan's ruling): - `name` — scope back to its ergonomic home: the identifier a `pick` selects by. Revert #236's cross-context-reference over-scope in name.schema.yaml + name.mdx; uniqueness is only "distinct among a pick's alternatives". (The #238 Context.Name TS type stays valid.) - `activation` — a new opaque-string correlation id living INSIDE the invoke/return/revert objects. The invoke that opens an activation and the return/revert that closes it carry the same value; distinct activations carry distinct values, unique per program. Symmetric (no declare/reference asymmetry) and flat — a tailcall back-edge's co-located return+invoke each carry their own `activation`, no `gather` forced. invoke.mdx: replace "Correlating with `name`" with "Correlating with `activation`" — id-based pairing, order-independent, push/pop the id-less fallback; membership stays marker-only. Kept out of the shared function-identity schema (identity = which function; activation = which instance). Spec + schema only; TS types (activation on Invoke/Return/Revert) follow separately. * format: tighten activation prose per review (membership scope, 'identifies') Per writer review of #240: (A) the opening of 'Correlating with activation' lumped membership into the well-nested-order clause, but membership is the order-independent inline marker (as the section's own para 4 says) — the blind spot is a pure push/pop pairing problem. Scope the sentence to push/pop only. (B) 'activation names which instance' → 'identifies', avoiding an echo of the now-disentangled name context.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Implements the approved #26 design (gnidan + team-lead sign-off, per-program uniqueness confirmed). Format spec + schema-description change only — no schema structure change, no code.
Why
namewas always intended as the machine-generated identifier for a context that other contexts reference by name — the #179 "pick disambiguation label" framing undersold it. This states that purpose clearly and applies it as the invoke/return correlation id, which is the principled fix for the two cases push/pop + theinlinemarker alone cannot handle (identified during the #23 inline work):returnmoved ahead of itsinvokedefeats strict push/pop pairing.Distinct per-activation names resolve both, order-independently.
What changes
name.schema.yaml— rewrite the description: a machine-generated identifier, referenceable by other contexts, unique within a program (oneinstructionssequence). Refreshed examples. No structural change (still{ name: string }).name.mdx— framenamefirst as the general referenceable-context-name primitive, thenpickselection and invoke/return correlation as applications. Notes that co-located facts needing distinct names (e.g. a tailcall's return+invoke) usegather, one name per member.invoke.mdx— add a "Correlating withname" subsection to Reconstructing activations: aninvokedeclares an activation's name,return/membership reference it; when present, names are authoritative for activation structure, with push/pop + marker-count as the name-less fallback (they agree in well-nested output; where they can't, names win).Model notes (from the design thread)
name≠invoke.identifier(per-activation vs per-function): twodblsites share the identifier but get distinct names.Compiler emission (bugc inlining pass → per-activation names) and UI consumption are deferred — this PR freezes the spec shape first. Full design write-up in the #26 proposal.