A bare number follows JSON rules, and a leading zero is text

[tobert]

kaish -c '/bin/echo -0 007 010 0.10 1.0' printed 0 7 10 0.1 1. Each word was lexed to a typed number and rendered back from the value, so the text was lost before execve saw it. Any identifier made of digits — a UID, a mode, a zero-padded ID — arrived wrong, with no error.

The rule: a leading zero means text; where kaish needs a number, a leading zero is an error.

007, 010, and 00 are strings. fromjson '007' already refused them as invalid JSON, and a bare word now agrees. That keeps chmod 0644 file working exactly as typed, which is the common case and the one bash gets right.

-0, 0.10, and 1.0 are valid JSON numbers and stay numbers. Their argv fidelity comes from the source text carried alongside the value — on the AST literal, on ToolArgs so builtins keep it, and on redirect targets.

Where a real number is required, the error names the number to write:

break 007            error — write `break 7`
echo $((010 + 1))    error — kaish reads no octal; write `10`
xs=[10 20]
echo ${xs[007]}      error — a list is indexed by number; write ${xs[7]}

Arithmetic is the case worth stating plainly: bash reads 010 as octal and answers 9, decimal would answer 11, so kaish refuses rather than quietly picking a third answer.

A slice bound is a number position too, and that one was silent: ${xs[007:2]} parsed 007 as 7, inverted the range, and returned an empty list with exit 0. Both bounds refuse a leading zero now, and the four ordinary spellings ([0:2], [:2], [1:], [-2:]) are pinned by their own test.

Two things the rule gives back. A record key that is a leading-zero numeral now round-trips — ${r[007]} reads the "007" key instead of normalizing to index 7, and r[007]=v is no longer a parse error, so the read and the write finally name the same key. And --plan and execution agree on redirect targets: echo hi > -0 reported -0 in the plan document and created a file named 0.

A help numbers topic teaches the rule, and documents one limit: a variable copy does not carry the source text, so x=-0; echo $x prints 0.

Comparison follows from the same rule: [[ 007 == 7 ]] is false, as in bash, and a numeric comparison is a number position — [[ 010 -eq 10 ]] and test 08 -eq 8 are refused with the same message as $((010)). bash answers 8 there (octal) and kaish used to answer 10; refusing is the only answer that is not a third number. Two compat pins that asserted the old decimal reading are retired; the refusal is pinned in leading_zero_tests.

An integer past 64 bits is an error that names the limit and the fix — does not fit in a 64-bit integer (-9223372036854775808..9223372036854775807); quote it to keep the text — shared by the lexer, arithmetic, and [[ -eq ]]. That last one closed a silent hole: [[ "9223372036854775808" -eq 9223372036854775807 ]] was true because both sides rounded to the same f64; a string now falls to f64 only when it is spelled as a float. A leading-zero numeral that also overflows (09223372036854775808) is text, as any leading-zero word is.

Arithmetic refuses the numeral however it arrives, so x=010; echo $((x)) is refused the same way the literal is — it answered 10 where bash answers 8.

The break/continue message is derived after the grammar has already failed, and it is gated twice: the grammar's own error must sit on that numeral, and break must be in statement position. Either gate alone lets it answer for something it never judged — echo break 007 fails on the numeral too, and without the position gate an unrelated error elsewhere on the line got this message instead of its own.

Checked against a real corpus rather than only synthetic cases: kaijutsu's contrib/kai-parse-check.sh parses 71 committed .kai scripts — gate logic with heredocs, nested $(), jq filters and case ladders. 71/71 on main and 71/71 here, with a known-bad file run first to confirm the gate can fail.

One residual, not fixed here: about fifteen call sites hand-roll "prefer the source text, else stringify." The redirect target was a missed copy of that decision, and the next consumer of Expr can miss it the same way.

🤖 Generated with Claude Code

[tobert]

Mostly LGTM. The comments seem to repeat a lot of what is in or should be in LANGUAGE.md. Please address then we can merge.

[tobert]

Addressed the review.

The rule was restated at nine kernel.rs call sites, each re-explaining that a non-canonical numeral keeps its source text and that 007 is a different case. docs/LANGUAGE.md already teaches both under "A bare number follows JSON rules", so it is stated once on Token::NumericLiteral and Expr::NumericLiteral, which point there, and each call site now says only what is true at that site. 378 comment lines against 772 of code, now 283.

One piece of reasoning stayed: the bash-octal explanation in arithmetic.rs. Refusing rather than answering a third number is why that arm exists, and nothing else on the line says so.

Gates green locally: cargo test --all, cargo clippy --all --all-targets -- -D warnings, and the rustdoc leg.

[tobert]

kaibo review (cast deepseek, pointed at the worktree with this branch checked out). It had not had one. Every claim below was verified against built binaries for both main and this branch before acting on it.

Two real problems, both fixed:

break -0 was a regression this branch introduced. The count grammar matches only Token::Int, and carrying source text moved -0 to Token::NumericLiteral. main exits 0, this branch exited 2. break -1 and break 0 were never affected, so it was exactly the -0 spelling this branch's own LANGUAGE.md calls a valid number.

exec never got the rule. It builds argv at its own edge rather than through build_args_flat:

/bin/echo -0 007 0.10        -0 007 0.10
exec /bin/echo -0 007 0.10   0 007 0.1     <- disagreed

Both fixes have a test that fails without them. The exec test spawns the real binary: written in-process it execve'd over the test harness, so 11 of 48 tests ran, the harness became /bin/echo, and the run still exited 0.

Not treated as regressions, contrary to how the review framed them. The builtin path operands (rm, mkdir, cp, ~40 sites) lose -0/0.10 on main and on this branch alike — mkdir 0.10 makes 0.1 either way. That is the residual this PR body already names, not something it breaks. 007 is correct everywhere now because it became a string.

Also confirmed, both pre-existing: 0e5 is a string here while fromjson '0e5' is a number, because the lexer has no exponent rule; and is_glob_mergeable matches Int but not Float, so a comment overstated it — corrected.

Gates green: cargo test --all, cargo clippy --all --all-targets -- -D warnings, the rustdoc leg, and --no-default-features.