Skip to content

Measure Go's elidable material, and correct the sequencing warning - #25

Merged
ojassug merged 1 commit into
mainfrom
measure-go-elision-precondition
Aug 15, 2026
Merged

Measure Go's elidable material, and correct the sequencing warning#25
ojassug merged 1 commit into
mainfrom
measure-go-elision-precondition

Conversation

@ojassug

@ojassug ojassug commented Aug 15, 2026

Copy link
Copy Markdown
Collaborator

Precondition check for widening elision past TypeScript/JavaScript/Python — the one roadmap item still open. Measured before writing any of it. Docs only; no source changes.

The material

Ceiling = share of bytes inside func bodies clearing the shipped filters (MIN_REGION_BYTES 104, isSubstantiveRegion) on scanBraceSpans's between-brace boundary. TypeScript and Python measured with the shipped selectElisionRegions over the frozen corpus.

corpus files ceiling, non-test ceiling, all median/file no region
Go — app (cli/cli, cobra, gin) 1,028 65.36% 81.44% 63.3% 9.5%
Go — stdlib (golang/go src/) 5,387 54.78% 59.81% 39.5% 28.2%
TypeScript — this repo 62 57.78% 58.6% 11.3%
Python — pip 45 46.88% 53.8% 2.2%

TypeScript turns 57.78% into 24.56% achieved at target 0.3, so Go projects to 23–28% — at or above the product's best language. The precondition holds.

The sequencing warning was wrong, in the dangerous direction

All three documents said "add the scanner alone and §33's measurement gate refuses the item, converting a 0% into a fallback." Measured, that holds only for a file with no struct, class or import:

case symbolsBefore S_k astMeasured measurementGate fallback
Go with struct/import type:Point, import:fmt 0.0000 true pass false
Go without either (none) 0.0000 false refuse true

extractSymbols yields no function symbols at all for Go, C, Java or Rust — type:Point and import:fmt are incidental matches by the TypeScript regexes, and both survive body elision by construction because signatures are retained. On real source, which nearly always carries a struct or import, scanner-first passes every gate while measuring nothing. Every function body could be deleted and S_k stays 0.0000.

This is C1's shape one step over, and §33 does not cover it: §33 closed "the before-set is empty so R_AST defaults to 1.0"; this is the sibling where the before-set is non-empty but structurally incapable of registering the loss.

Order, for that reason: extractSymbols → validator → REGION_ELISION_LANGUAGES + scanner. Step 1 alone is a free negative control.

The claim is struck through in all three documents rather than deleted, with the measurement beside it — including text added earlier the same day. Leaving a disproven statement standing in a third document is this project's own recurring failure.

Two findings worth more than the headline

Test files are the larger prize. _test.go is 53 MB against 36 MB of source in the app corpus, at 92.22% elidable with 0.7% having no region. Nothing in this project has been counting them.

The ceiling is not the constraint; the gates are. Target 0.9 gives TypeScript 21.37% with 25 files unchanged, against 24.56% with 12 at target 0.3 — pushing harder trips the constraint and drift gates. §48 reproduced; it bounds Go too.

Method

The cross-check moved the number and that is why it was run: app-only read 65.36%, the stdlib pulled it to 54.78%, and the cause was checked rather than averaged — 21.7% of stdlib source bytes are in files with no elidable region, dominated by generated tables the DO NOT EDIT filter missed (opGen.go alone is 3.99 MB). One corpus would have overstated this by ten points.

The instrument was validated before the result was believed: 12/12 cases including raw-string literals, both comment forms, interface methods with no body, and closures counted once.

Not established: the 23–28% projection borrows TypeScript's conversion factor, which embeds TypeScript's fallback rate. Go's own is unmeasurable until the validator and extractSymbols exist.

669 tests, typecheck, lint and build green.

🤖 Generated with Claude Code

Precondition check for widening elision past TypeScript/JavaScript/Python -- the
one roadmap item still open. Measured before writing any of it. DECISIONS §56,
status doc §9.

The material. Ceiling is the share of bytes inside func bodies clearing the
shipped filters (MIN_REGION_BYTES 104, isSubstantiveRegion) on scanBraceSpans'
between-brace boundary. TypeScript and Python measured with the shipped
selectElisionRegions over the frozen corpus:

  Go app (cli/cli, cobra, gin)   1028 files   65.36% non-test   81.44% all
  Go stdlib (golang/go src/)     5387 files   54.78% non-test   59.81% all
  TypeScript (this repo)           62 files   57.78%
  Python (pip)                     45 files   46.88%

TypeScript turns 57.78% into 24.56% achieved at target 0.3, so Go projects to
23-28% -- at or above the product's best language. The precondition holds.

The cross-check earned its keep. App-only read 65.36% and the stdlib pulled it to
54.78%; the cause was checked rather than averaged. 21.7% of stdlib source bytes
sit in files with no elidable region, dominated by generated tables the DO NOT
EDIT filter missed (opGen.go alone is 3.99 MB) plus a long tail of tiny files.
That content is atypical of what a coding assistant is pointed at, so the honest
range is 55-65%, not 65%. One corpus would have overstated this by ten points --
§4's bias trap arriving on the feature side, which is why §52 says not to trust a
single corpus.

The sequencing warning was wrong, and in the dangerous direction. ROADMAP and
status doc §7 both said: add the region scanner alone and §33's measurement gate
refuses the item, converting a 0% into a fallback. Measured, that holds only for
a file with no struct, class or import:

  go WITH struct+import   symbols type:Point,import:fmt   S_k 0.0000
                          astMeasured true   measurementGate PASS   no fallback
  go WITHOUT either       symbols (none)                  measurementGate refuse
  c  WITHOUT struct       symbols (none)                  measurementGate refuse

extractSymbols yields no function symbols at all for Go, C, Java or Rust --
type:Point and import:fmt are incidental matches by the TypeScript regexes, and
both survive body elision by construction because signatures are retained. So on
real source, which nearly always carries a struct or import, scanner-first passes
every gate while measuring nothing. Every function body could be deleted and S_k
stays 0.0000.

This is C1's shape one step over and §33 does not cover it: §33 closed "the
before-set is empty so R_AST defaults to 1.0", and this is the sibling where the
before-set is non-empty but structurally incapable of registering the loss. The
gate asks whether evidence existed, not whether it could witness this transform.

Order, for that reason: extractSymbols, then the validator, then
REGION_ELISION_LANGUAGES plus the scanner. Step 1 alone is a free negative
control -- reduction must stay 0% everywhere while drift on a hand-elided file
becomes non-zero.

Two findings worth more than the headline. Test files are the larger prize: in
the app corpus _test.go is 53 MB against 36 MB of source, at 92.22% elidable with
0.7% having no region, and nothing in this project has been counting them. And
the ceiling is not the constraint -- target 0.9 gives TypeScript 21.37% with 25
files unchanged against 24.56% with 12 at target 0.3, because pushing harder
trips the constraint and drift gates. §48 reproduced; it bounds Go too.

Not established: the 23-28% projection borrows TypeScript's conversion factor,
which embeds TypeScript's fallback rate. Go's own is unmeasurable until the
validator and extractSymbols exist.

The instrument was validated before the result was believed -- 12/12 cases
including raw-string literals, both comment forms, interface methods with no
body, and closures counted once.

669 tests, typecheck, lint and build green. No source changes.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@ojassug
ojassug merged commit fb6e4b7 into main Aug 15, 2026
3 checks passed
@ojassug
ojassug deleted the measure-go-elision-precondition branch August 15, 2026 14:50
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