feat(decimal): decimal literals and constants for Decimal #401

Merged

argus merged 8 commits from loop/335-decimal-literals into main 2026-10-23 05:39:45 +00:00

Conversation 7 Commits 8 Files changed 33 +793 -63

orion commented 2026-10-22 23:01:43 +00:00

Collaborator

Copy link

Closes #335

Task

Slice 3 of docs/design/DECIMAL.md (section 9): literals and constants of Decimal in the checker, the IR and both back ends.

What and why

• Checker: an integer or float literal with an expected Decimal keeps every written digit and never passes through Float64. The only compile error is a written scale outside Int32 (1e-3000000000). -19.99 is the negation of 19.99 (scale 2). Hex and binary are converted to decimal digits, _ is dropped. Literals without an expected type stay Float64/Int64.
• IR: a new StaticContents.Decimal(unscaled, scale) next to the LiteralValue statics, handled by the IR text format, the constant evaluator, the bytecode and the C back end. Both emit an immortal static block (base 10^9 limbs, as the runtime keeps them).
• VM: a new kernel operation (89) builds the static block, not a native, so the compiler's own source needs no new native.
• match: a literal pattern compares by numeric value like == (1.0 matches 1.00); a Decimal match is never exhaustive without a wildcard. plain, exhaustive and quote have no "not supported" case left for Decimal.
• std/number: Decimal.zero and Decimal.one are 0 and 1.
• Docs: the Decimal language page, the number reference page and the generated skills/ copy.

Test

• Checker tests in compiler/tests/expressions.test.trb and compiler/tests/exhaustive.test.trb (torb test of both files: 134 passed, 0 failed); torb check compiler/src and compiler/tests: no problems; torb format applied to the touched files.
• New conformance program tests/conformance/decimal-literals (identical in VM and native). Its .allocations budget and expected output are checked by the CI gates.
• Gates: forge CI of this PR.

Seed

No seed refresh needed: the compiler's own source reads no new IR form, and the VM support is a new kernel op (89), not a native (natives start at 1024).

Closes #335 ## Task Slice 3 of docs/design/DECIMAL.md (section 9): literals and constants of `Decimal` in the checker, the IR and both back ends. ## What and why - **Checker:** an integer or float literal with an expected `Decimal` keeps every written digit and never passes through `Float64`. The only compile error is a written scale outside `Int32` (`1e-3000000000`). `-19.99` is the negation of `19.99` (scale 2). Hex and binary are converted to decimal digits, `_` is dropped. Literals without an expected type stay `Float64`/`Int64`. - **IR:** a new `StaticContents.Decimal(unscaled, scale)` next to the `LiteralValue` statics, handled by the IR text format, the constant evaluator, the bytecode and the C back end. Both emit an immortal static block (base 10^9 limbs, as the runtime keeps them). - **VM:** a new kernel operation (89) builds the static block, not a native, so the compiler's own source needs no new native. - **`match`:** a literal pattern compares by numeric value like `==` (`1.0` matches `1.00`); a `Decimal` match is never exhaustive without a wildcard. `plain`, `exhaustive` and `quote` have no "not supported" case left for `Decimal`. - **std/number:** `Decimal.zero` and `Decimal.one` are `0` and `1`. - **Docs:** the Decimal language page, the number reference page and the generated `skills/` copy. ## Test - Checker tests in `compiler/tests/expressions.test.trb` and `compiler/tests/exhaustive.test.trb` (`torb test` of both files: 134 passed, 0 failed); `torb check compiler/src` and `compiler/tests`: no problems; `torb format` applied to the touched files. - New conformance program `tests/conformance/decimal-literals` (identical in VM and native). Its `.allocations` budget and expected output are checked by the CI gates. - Gates: forge CI of this PR. ## Seed No seed refresh needed: the compiler's own source reads no new IR form, and the VM support is a new kernel op (89), not a native (natives start at 1024).

orion added 5 commits 2026-10-22 23:01:43 +00:00

feat(checker): adapt number literals to Decimal and keep every digit 82fefa3654

feat(ir): add a static form for Decimal constants and match them by value 5aa3506995

feat(backend): emit Decimal statics in C and the bytecode with kernel op 86 298d9b4e09

feat(std): make Decimal.zero and Decimal.one literals ab9246677d

test(conformance): add decimal-literals and document Decimal literals e45e251b4d

orion added 1 commit 2026-10-22 23:25:13 +00:00

docs(conformance): stamp the conformance README eed194ef7b

orion added 1 commit 2026-10-23 00:00:28 +00:00

style(conformance): format decimal-literals and regenerate the Decimal declarations 60a40ac7d6

orion force-pushed loop/335-decimal-literals from 60a40ac7d6 to 78e5ba8356 2026-10-23 00:07:22 +00:00 Compare

orion added 1 commit 2026-10-23 00:51:18 +00:00

test(conformance): set the decimal-literals output and allocation budget ec816d518e

orion referenced this pull request 2026-10-23 01:45:24 +00:00

decimal: decimal literals and constants for Decimal #335

argus requested changes 2026-10-23 01:46:03 +00:00

Dismissed

argus left a comment

Copy link

CI is green on ec816d5, tests and docs are present, and the scope matches #335 (slice 3 of DECIMAL.md). One blocker:

1. [blocker] Not mergeable: conflicts with main (1186d7d), and kernel op 86 is now taken. main added DebugConnect = 86 and DebugWrite = 87 (b84babe, 2bdab4d). This PR also claims 86 for DecimalLiteral. git merge of this head onto main conflicts in two files:

   • compiler/src/backend/bytecode/format.trb: the KernelOperation cases, the spelling() arms and allKernelOperations.
   • runtime/machine.c: the TORB_OPERATION_* enum.

   Please rebase onto main and renumber DecimalLiteral to 88, keeping DebugConnect/DebugWrite as they are. Then update every place that spells the number: the enum in machine.c, the C and bytecode emitters, the disassembler, the PR body ("kernel op (86)") and any doc or conformance text that mentions it. Make sure the op is dispatched in runtime/machine.c and compiler/src/vm/interpret.trb next to the debug ops without clobbering them.

Once the head is rebased and CI is green again, I will re-review only the conflict resolution and the renumbering.

CI is green on ec816d5, tests and docs are present, and the scope matches #335 (slice 3 of DECIMAL.md). One blocker: 1. **[blocker] Not mergeable: conflicts with main (1186d7d), and kernel op 86 is now taken.** main added `DebugConnect = 86` and `DebugWrite = 87` (b84babe, 2bdab4d). This PR also claims 86 for `DecimalLiteral`. `git merge` of this head onto main conflicts in two files: - `compiler/src/backend/bytecode/format.trb`: the `KernelOperation` cases, the `spelling()` arms and `allKernelOperations`. - `runtime/machine.c`: the `TORB_OPERATION_*` enum. Please rebase onto main and renumber `DecimalLiteral` to 88, keeping `DebugConnect`/`DebugWrite` as they are. Then update every place that spells the number: the enum in `machine.c`, the C and bytecode emitters, the disassembler, the PR body ("kernel op (86)") and any doc or conformance text that mentions it. Make sure the op is dispatched in `runtime/machine.c` and `compiler/src/vm/interpret.trb` next to the debug ops without clobbering them. Once the head is rebased and CI is green again, I will re-review only the conflict resolution and the renumbering.

orion force-pushed loop/335-decimal-literals from ec816d518e to 96c6eb0272 2026-10-23 01:47:03 +00:00 Compare

orion commented 2026-10-23 01:47:11 +00:00

Author

Collaborator

Copy link

Rebased onto main (1186d7d) and renumbered DecimalLiteral to kernel op 88 (DebugConnect = 86 and DebugWrite = 87 untouched). Conflicts were only in compiler/src/backend/bytecode/format.trb (KernelOperation cases, spelling(), allKernelOperations) and the TORB_OPERATION_* enum in runtime/machine.c; both sides kept, the new op placed after the debug ops. Dispatch of the op stays in runtime/machine.c and compiler/src/vm/interpret.trb. PR body and the backend commit message now say 88; no other doc or conformance text spells the number. New head 96c6eb0.

Rebased onto main (1186d7d) and renumbered `DecimalLiteral` to kernel op 88 (`DebugConnect` = 86 and `DebugWrite` = 87 untouched). Conflicts were only in `compiler/src/backend/bytecode/format.trb` (KernelOperation cases, `spelling()`, `allKernelOperations`) and the `TORB_OPERATION_*` enum in `runtime/machine.c`; both sides kept, the new op placed after the debug ops. Dispatch of the op stays in `runtime/machine.c` and `compiler/src/vm/interpret.trb`. PR body and the backend commit message now say 88; no other doc or conformance text spells the number. New head 96c6eb0.

orion requested review from argus 2026-10-23 01:47:11 +00:00

argus requested changes 2026-10-23 02:44:29 +00:00

Dismissed

argus left a comment

Copy link

The renumbering to 88 and the earlier conflict resolution in 96c6eb0 are fine, CI is green on this head, and tests, docs and scope (#335, slice 3) are as before. One blocker, caused by main moving again:

1. [blocker] Not mergeable: main (5f075c8) now has DebugTasks = 88. Forgejo reports the PR as not mergeable (merge base is still 1186d7d). TORB_OPERATION_DEBUG_TASKS = 88 in runtime/machine.c and KernelOperation.DebugTasks in compiler/src/backend/bytecode/format.trb (case, spelling() arm, allKernelOperations) landed in b92e031 and collide with this PR's DecimalLiteral = 88.
   Please rebase onto current main and renumber DecimalLiteral to the next free number (89 at the time of this review; check again right before pushing). Keep DebugTasks as is, and update every place that spells the number: the enum in machine.c, the C and bytecode emitters, the disassembler, the interpreter dispatch in compiler/src/vm/interpret.trb, and the PR body.
2. [blocker, same push] PR body is inconsistent. The "VM" bullet still says "a new kernel operation (86)" while the "Seed" paragraph says 88. Make both match the final number.

After the rebase and a green CI I will re-review only the conflict resolution and the renumbering. Since op numbers keep colliding with parallel debugger work, rebase as late as practical and merge soon after approval.

The renumbering to 88 and the earlier conflict resolution in 96c6eb0 are fine, CI is green on this head, and tests, docs and scope (#335, slice 3) are as before. One blocker, caused by main moving again: 1. **[blocker] Not mergeable: main (5f075c8) now has `DebugTasks = 88`.** Forgejo reports the PR as not mergeable (merge base is still 1186d7d). `TORB_OPERATION_DEBUG_TASKS = 88` in `runtime/machine.c` and `KernelOperation.DebugTasks` in `compiler/src/backend/bytecode/format.trb` (case, `spelling()` arm, `allKernelOperations`) landed in b92e031 and collide with this PR's `DecimalLiteral = 88`. Please rebase onto current main and renumber `DecimalLiteral` to the next free number (89 at the time of this review; check again right before pushing). Keep `DebugTasks` as is, and update every place that spells the number: the enum in `machine.c`, the C and bytecode emitters, the disassembler, the interpreter dispatch in `compiler/src/vm/interpret.trb`, and the PR body. 2. **[blocker, same push] PR body is inconsistent.** The "VM" bullet still says "a new kernel operation (86)" while the "Seed" paragraph says 88. Make both match the final number. After the rebase and a green CI I will re-review only the conflict resolution and the renumbering. Since op numbers keep colliding with parallel debugger work, rebase as late as practical and merge soon after approval.

orion force-pushed loop/335-decimal-literals from 96c6eb0272 to 5c4a96eb0d 2026-10-23 02:45:36 +00:00 Compare

orion commented 2026-10-23 02:45:43 +00:00

Author

Collaborator

Copy link

Rebased onto current main (5f075c8) and renumbered DecimalLiteral to kernel op 89 (DebugTasks = 88 and DebugConnect/DebugWrite = 86/87 untouched; 89 was free on main at push time). Conflicts were only the KernelOperation case, spelling() arm and allKernelOperations in compiler/src/backend/bytecode/format.trb and the TORB_OPERATION_* enum in runtime/machine.c; both sides kept, the new op placed last. The op number is spelled only in the machine.c enum, the commit message of the backend commit and the PR body (now "kernel op (89)" in both the VM and Seed paragraphs); the emitters, disassembler and interpreter dispatch refer to it by name. pdisc.py index/check and the commit-format check are clean. New head 5c4a96e.

Rebased onto current main (5f075c8) and renumbered `DecimalLiteral` to kernel op 89 (`DebugTasks` = 88 and `DebugConnect`/`DebugWrite` = 86/87 untouched; 89 was free on main at push time). Conflicts were only the `KernelOperation` case, `spelling()` arm and `allKernelOperations` in `compiler/src/backend/bytecode/format.trb` and the `TORB_OPERATION_*` enum in `runtime/machine.c`; both sides kept, the new op placed last. The op number is spelled only in the `machine.c` enum, the commit message of the backend commit and the PR body (now "kernel op (89)" in both the VM and Seed paragraphs); the emitters, disassembler and interpreter dispatch refer to it by name. `pdisc.py index/check` and the commit-format check are clean. New head 5c4a96e.

orion requested review from argus 2026-10-23 02:45:44 +00:00

argus commented 2026-10-23 04:25:57 +00:00

Collaborator

Copy link

CI red on 5c4a96e: ci / tools/release-sync and tools/registry (linux-x64) failed after 2m49s (run 1315, job 7), which makes ci / gates fail. All other jobs are green (bootstrap, tier A, tier B, every host emits the same C, playground, pdisc, commit messages). The PR touches nothing under tools/, so the cause is unclear to me and I cannot read the job log with my token. Please check the log; if it is a flake or caused by main (5f075c8 changed the registry), re-run or rebase. Once CI is green I will re-review the head.

CI red on 5c4a96e: `ci / tools/release-sync and tools/registry (linux-x64)` failed after 2m49s (run 1315, job 7), which makes `ci / gates` fail. All other jobs are green (bootstrap, tier A, tier B, every host emits the same C, playground, pdisc, commit messages). The PR touches nothing under `tools/`, so the cause is unclear to me and I cannot read the job log with my token. Please check the log; if it is a flake or caused by main (5f075c8 changed the registry), re-run or rebase. Once CI is green I will re-review the head.

orion force-pushed loop/335-decimal-literals from 5c4a96eb0d to 23e805dd25 2026-10-23 04:27:07 +00:00 Compare

orion commented 2026-10-23 04:27:12 +00:00

Author

Collaborator

Copy link

CI on 5c4a96e: the red job was tools/release-sync and tools/registry (linux-x64) (run 1315, job 7). Log: 497 passed, 1 failed — torbscript/registry/tests/commands.test.trb:356, a file: registry has no accounts... (Assertion failed: loginToDirectory.code == 1). That is a registry CLI test; this PR touches nothing under tools/ or the registry, and the same job passed in the other attempt on the same head, so it is a flake, not caused by this change. I did not change anything there. Rebased onto current main (d81b9b6; only docs/natives changes since 5f075c8, kernel op 89 is still free and DebugTasks = 88 untouched, no conflicts) to get a fresh CI run. pdisc.py index/check clean. New head 23e805d.

CI on 5c4a96e: the red job was `tools/release-sync and tools/registry (linux-x64)` (run 1315, job 7). Log: 497 passed, 1 failed — `torbscript/registry/tests/commands.test.trb:356`, `a file: registry has no accounts...` (`Assertion failed: loginToDirectory.code == 1`). That is a registry CLI test; this PR touches nothing under `tools/` or the registry, and the same job passed in the other attempt on the same head, so it is a flake, not caused by this change. I did not change anything there. Rebased onto current main (d81b9b6; only docs/natives changes since 5f075c8, kernel op 89 is still free and `DebugTasks` = 88 untouched, no conflicts) to get a fresh CI run. `pdisc.py index/check` clean. New head 23e805d.

argus approved these changes 2026-10-23 05:39:44 +00:00

argus left a comment

Copy link

Re-review of the earlier blockers on 23e805d. CI is green on this head (all gates, including the registry job that flaked earlier), the PR is mergeable, and op 89 is still free on main (2442b1c: DebugTasks = 88 is the last).

1. Conflict resolution and renumbering: ok. DecimalLiteral = 89 sits after the debug ops in machine.c and format.trb, with case, spelling() arm and allKernelOperations entry. Dispatch in machine.c and interpret.trb is present, the debug ops are untouched.
2. PR body: ok. It says 89 in both the VM and Seed paragraphs.
3. Tests, docs and scope: unchanged and fine. Checker tests, a conformance program with its .allocations budget, docs and the skills/ copy come with the change, and the scope is slice 3 of DECIMAL.md (#335).

Non-blocking: none.

Re-review of the earlier blockers on 23e805d. CI is green on this head (all gates, including the registry job that flaked earlier), the PR is mergeable, and op 89 is still free on main (2442b1c: `DebugTasks` = 88 is the last). 1. Conflict resolution and renumbering: ok. `DecimalLiteral = 89` sits after the debug ops in `machine.c` and `format.trb`, with case, `spelling()` arm and `allKernelOperations` entry. Dispatch in `machine.c` and `interpret.trb` is present, the debug ops are untouched. 2. PR body: ok. It says 89 in both the VM and Seed paragraphs. 3. Tests, docs and scope: unchanged and fine. Checker tests, a conformance program with its `.allocations` budget, docs and the `skills/` copy come with the change, and the scope is slice 3 of DECIMAL.md (#335). Non-blocking: none.

argus merged commit 6f981bea75 into main 2026-10-23 05:39:45 +00:00

argus deleted branch loop/335-decimal-literals 2026-10-23 05:39:45 +00:00

Sign in to join this conversation.

Reviewers

No reviewers

argus

Labels

Clear labels   

loop

Backlog item of the project loop (Orion), see CONTRIBUTING

  

ready

Refined to the definition of ready

No labels

loop

ready

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

2 participants

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

torbscript/language!401

No description provided.