Skip to content

refactor(comp): compact native ops and share match/JS program builders - #940

Closed
This-Is-NPC wants to merge 3 commits into
bendlang:mainfrom
This-Is-NPC:refactor/comp-native-tables
Closed

This-Is-NPC wants to merge 3 commits into
bendlang:mainfrom
This-Is-NPC:refactor/comp-native-tables

Conversation

@This-Is-NPC

Copy link
Copy Markdown

bend2/comp.ts only. Same language, same Base, same #| contract.

The C and JS lanes repeated native op entries, Nat/U32 table matching, and the JS program wrapper. This collapses that duplication without changing emitted semantics.

  • Native ops go through both / js_op; OPERATIONS and OPTIMIZED are the compact tables.
  • C and JS table matches share mat_tab.
  • js_book and io_run share js_prog.
  • Fid/cid macros in the C runtime stay equivalent, with the blank lines dropped.

Net: −121 lines (65916470; +92 / −213).

Factor C/JS native entries through both and js_op, and collapse the
native constructor tables. Runtime macros for fid/cid stay equivalent.
C and JS both built the same Nat/U32 table match; mat_tab is the one
path both emitters use.
js_book and the interpreter's JS lane both assembled the same program
text; js_prog is the one builder.
@zxv

zxv commented Sep 22, 2026

Copy link
Copy Markdown

rescuing PR by commenting (github bug hid it temporarily)

@nicolas-abril nicolas-abril self-assigned this Sep 22, 2026
@nicolas-abril

Copy link
Copy Markdown
Collaborator

Thanks for the contribution! Reducing duplication and simplifying the compiler is a good direction, but I’m going to close this PR because several changes feel more like token minimization than improvements in clarity.

In particular, both and js_op save tokens without really simplifying the logic, and both doesn’t clearly describe its purpose. The changes around OPTIMIZED also make the code a little harder to follow. We want token savings to come from simpler code, rather than making the same logic more compact.

The mat_tab extraction looks promising, though I’d prefer an emit_... name and a simpler return type. I also like the direction of js_prog, but its current benefit seems small relative to the extra layer of abstraction.

You’re welcome to open a new PR focused on those two pieces, with cleaner interfaces and, ideally, some simplification of the underlying logic. Thanks again for taking the time to work on this!

Note: this reply was written by an AI after it reported the PR to me and I made the decision. If anything here is wrong, reply and I will review it myself.

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.

3 participants