format: correct activation correlation — activation id inside invoke/return/revert, scope name to pick#240
Merged
Merged
Conversation
…` 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.
Contributor
|
…ifies') 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.
gnidan
added a commit
that referenced
this pull request
Jul 3, 2026
The activation-id correction (#240 schema) adds an optional `activation` string on the invoke, return, and revert context objects — the opening invoke and the closing return/revert share the same value to pair an activation independent of trace order. Mirror that in the TS types: add `activation?: string` to Invoke.Invocation, Return.Info, and Revert.Info. Placed per-object to track the schema (activation is added on each of invoke/return/revert, not on the shared context/function identity schema). No guard change — activation is an optional field on an existing object, not a new context discriminator.
gnidan
added a commit
that referenced
this pull request
Jul 3, 2026
…241) The activation-id correction (#240 schema) adds an optional `activation` string on the invoke, return, and revert context objects — the opening invoke and the closing return/revert share the same value to pair an activation independent of trace order. Mirror that in the TS types: add `activation?: string` to Invoke.Invocation, Return.Info, and Revert.Info. Placed per-object to track the schema (activation is added on each of invoke/return/revert, not on the shared context/function identity schema). No guard change — activation is an optional field on an existing object, not a new context discriminator.
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.
Corrects the #236 correlation mechanism (gnidan's ruling, task #29). Format spec + schema only — no code, no structural break.
The flaw #236 had
#236 overloaded the
namecontext to also correlate invoke↔return. But a siblingnameinherently declares the context it sits in — so areturncarrying the samenameto "reference" the activation would be a second declaration of that name, violating the per-name uniqueness we froze. The declaration/reference asymmetry was right; the mechanism (one primitive for both roles) was not.The fix — two identifiers for two jobs
name→ scoped back to pick-selection (its ergonomic home: the identifier apickselects by). Reverts format: define contextnameas a referenceable identifier (activation correlation) #236's cross-context-reference over-scope inname.schema.yaml+name.mdx; uniqueness is only "distinct among apick's alternatives." The format: add Name context type and guard to TS types #238Context.NameTS type stays valid —nameisn't going away, just scoped.activation→ a new correlation id inside the call facts. An opaque string living inside theinvoke/return/revertobjects. 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.Why this is clean
activation; matching values pair them. No declare/reference asymmetry, no primitive doing a job it structurally can't.gatherforced — a tailcall back-edge's co-locatedreturn+invokeeach carry their ownactivationvalue as flat siblings:{ return: { …, activation: "iter3" }, invoke: { …, activation: "iter4" } }.activationis deliberately NOT on the shared function-identity schema (identity = which function; activation = which instance).Files
name.schema.yaml,name.mdx— revert to pick-selection framing.invoke.schema.yaml,return.schema.yaml,revert.schema.yaml— add optionalactivationstring (+ an example on the inlined invoke).invoke.mdx— swap "Correlating withname" → "Correlating withactivation": id-based pairing, order-independent, push/pop the id-less fallback. Membership stays marker-only (adversarial-reorder membership deferred).Verification
yarn workspace @ethdebug/format testgreen — 449 passed, incl. schema validity (70) + examples (317); the newactivationexample validates (confirms theproperties+$ref+unevaluatedPropertiesinteraction on invoke).Follow-ups: debugger adds
activationto theInvoke/Return/RevertTS types; compiler emission + UI pairing deferred until the shape is frozen here.