Skip to content

Exports evaluateTagged's result type by name - #202

Merged
johnnyt merged 1 commit into
mainfrom
pts-r69a-export-tagged-evaluation-type
Oct 4, 2026
Merged

johnnyt merged 1 commit into
mainfrom
pts-r69a-export-tagged-evaluation-type

Conversation

@johnnyt

@johnnyt johnnyt commented Oct 4, 2026

Copy link
Copy Markdown
Member

What

evaluateTagged answered ProjectedEvaluation, a type the ./tagged subpath did not export, so a host could name its result only through the function's return type. The same gap was closed for executeTagged's result type, TaggedExecution, before this.

  • src/tagged.ts: the subpath re-exports ProjectedEvaluation (declared in src/evaluator.ts) under the name the source already uses, with a doc comment saying how it relates to the main entry point's result type.
  • test/export-surface.json: the name is pinned in the ./tagged list.
  • test/tagged.test.ts: a test annotates an evaluateTagged result with the new name and widens it to EvaluateResult, so the typecheck stage reads both through the entries a host imports.
  • changelog.d/pts-r69a.md: an Added line.

No answer changes; the type gains an export and nothing else.

How the two names relate

The main entry point does not export ProjectedEvaluation. Its EvaluateResult is ProjectedEvaluation with a ParseError arm added, the arm a source text fails on. evaluateTagged takes a compiled instruction list only, so it answers no parse failure, and every value of ProjectedEvaluation is also an EvaluateResult. The new test pins that assignment.

Provenance

  • Exporting the type rather than recording why a host does not need it, and exporting it under its source name rather than a new one, follow the recommendation the change was scheduled with: decided by the conductor under a standing consent, 2026-10-03.
  • No record states the ./tagged subpath's full export list, so no record Note rides this change. ADR-0002 says TaggedEvaluateOptions is exported from that subpath and from no other entry point, which still holds. ADR-0005's Note on its acceptance commit list mentions TaggedExecution only as part of that commit, which is unchanged.

Checks

  • Full quality gate green locally on the committed tree.
  • Sabotage, each restored from a copy and proven byte-equal before the next:
    • the re-export replaced by a private alias of the type: the ./tagged export-surface pin went red on its assertion;
    • the re-export line deleted: the same pin went red on its assertion, and the typecheck stage went red on the test's import of the name.

evaluateTagged answered ProjectedEvaluation, a type the ./tagged
subpath did not export, so a host could name it only through the
function's return type. The subpath now re-exports it under the name
the source already uses. It is the main entry point's EvaluateResult
without the ParseError arm, so every value of it is also an
EvaluateResult. No answer changes.

The export-surface list pins the name, and a test annotates an
evaluateTagged result with it and widens it to EvaluateResult, so the
typecheck stage reads both through the entries a host imports.

Sabotage, each run and restored from a copy: dropping the re-export
turns the export-surface pin red on its assertion and the typecheck
stage red on the test's import.

Refs: pts-r69a
@johnnyt
johnnyt merged commit 9a2fb80 into main Oct 4, 2026
1 check passed
@johnnyt
johnnyt deleted the pts-r69a-export-tagged-evaluation-type branch October 4, 2026 19:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant