tmt ir graph emits one arrow per expanded rule row. On a wide program that is not a diagram any renderer can lay out, and the arrows are near-duplicates of each other.
Measured on v0.5.0 with docs/examples/rpnwide/rpnwide.tmc (14 tapes, 9 worlds, 65 states): 4,711 arrows, of which addInto and subInto carry 2,049 each (the 512-row rules the compiler already warns about), main 139. Every label is a fourteen-cell vector.
Merging rows that share source state, target state, write vector, move vector and transition — and collapsing their read patterns per cell into a set — brings main from 139 arrows to 46 with no loss of information: the sixteen call pushTok self-loops on scan (one per digit) become one arrow labeled [1–16,*×13] call pushTok. The arithmetic routines stay dense after merging (129 each) because their writes genuinely depend on the digit read; those want a "shape" view — one arrow per state pair, labeled with the row count — which is what a reader needs from them anyway.
Both renderings, with the per-world counts: https://claude.ai/code/artifact/7bc21967-eb6b-4ba4-859d-0164ea783587
Ask
- Merge parallel rows by default in
ir graph (both tools; pmt's CFG is less affected but the same rule applies to check fan-out). Per-cell union of the read patterns, rendered as ranges (1–16), with runs of identical cells compressed (*×13, .×13, -×13) so a fourteen-tape label fits on an arrow.
--shape (or a threshold flag) to collapse to one arrow per state pair with a row count, for the worlds where merging is not enough.- Keep
--raw (or the current behavior under a flag) for the row-for-row form, since it is the one that matches the listing one to one.
The .pmc side is a CFG of basic blocks and does not fan out this way; the ask there is only the shared label compression.
Relevant to the browser export of the IR / graph tracked in the sibling issue linked below: a demo panel will apply the same merge, and having it in the renderer means the CLI and the panel agree on what a merged label looks like.
Links
tmt ir graphemits one arrow per expanded rule row. On a wide program that is not a diagram any renderer can lay out, and the arrows are near-duplicates of each other.Measured on v0.5.0 with
docs/examples/rpnwide/rpnwide.tmc(14 tapes, 9 worlds, 65 states): 4,711 arrows, of whichaddIntoandsubIntocarry 2,049 each (the 512-row rules the compiler already warns about),main139. Every label is a fourteen-cell vector.Merging rows that share source state, target state, write vector, move vector and transition — and collapsing their read patterns per cell into a set — brings
mainfrom 139 arrows to 46 with no loss of information: the sixteencall pushTokself-loops onscan(one per digit) become one arrow labeled[1–16,*×13] call pushTok. The arithmetic routines stay dense after merging (129 each) because their writes genuinely depend on the digit read; those want a "shape" view — one arrow per state pair, labeled with the row count — which is what a reader needs from them anyway.Both renderings, with the per-world counts: https://claude.ai/code/artifact/7bc21967-eb6b-4ba4-859d-0164ea783587
Ask
ir graph(both tools;pmt's CFG is less affected but the same rule applies tocheckfan-out). Per-cell union of the read patterns, rendered as ranges (1–16), with runs of identical cells compressed (*×13,.×13,-×13) so a fourteen-tape label fits on an arrow.--shape(or a threshold flag) to collapse to one arrow per state pair with a row count, for the worlds where merging is not enough.--raw(or the current behavior under a flag) for the row-for-row form, since it is the one that matches the listing one to one.The
.pmcside is a CFG of basic blocks and does not fan out this way; the ask there is only the shared label compression.Relevant to the browser export of the IR / graph tracked in the sibling issue linked below: a demo panel will apply the same merge, and having it in the renderer means the CLI and the panel agree on what a merged label looks like.
Links