Missing unprefixed sugar for pow (i.pow has no bare alias) #489

New issue

Closed

opened 2026-05-16 01:16:43 +00:00 by navicore · 1 comment

navicore commented

2026-05-16 01:16:43 +00:00

Owner

Summary

i.pow is missing the unprefixed sugar alias that every other integer arithmetic / comparison op has. +, -, *, /, <, >, =, <>, etc. all resolve to their i.* counterparts when written bare, but pow does not.

Reproduction

: test-plus ( -- )   3 4 +   7 test.assert-eq ;     # ✓ resolves
: test-lt   ( -- )   3 4 <   true test.assert ;     # ✓ resolves
: test-pow  ( -- )   2 3 pow                        # ✗ Unknown word: 'pow'
    8 test.assert-eq
;

Run seqc lint on the third — error:

error [type-error]: Unknown word: 'pow'

The first two compile fine (modulo unrelated i./ Bool-flag bookkeeping for the / case).

Expected

pow should resolve to i.pow with the same ( Int Int -- Int Bool ) signature — matching how / resolves to i./ and keeps the Bool flag from i.modulo/i.divide.

Why this matters

Seq's design choice (per docs/language-guide.md) is that i. prefixes are required on the canonical word names but bare arithmetic/comparison ops resolve via implicit sugar. The sugar is undocumented in the language guide but it's clearly present (the examples above prove it). When i.pow was added, the sugar table wasn't updated alongside, leaving pow as an outlier among the arithmetic ops.

Knock-on effect: seqlings chapter 27 (the std:imath chapter) has an exercise that asks the student to type 2 10 pow — which mirrors the docs in STDLIB_REFERENCE.md and the surrounding sugar conventions, but doesn't compile.

Suggested fix

Wherever the bare-name sugar table for integer ops lives, add pow → i.pow.

If the language-guide doc-bug (sugar table not documented) is in scope, that's worth fixing in the same PR — currently a reader has to discover the sugar empirically.

## Summary `i.pow` is missing the unprefixed sugar alias that every other integer arithmetic / comparison op has. `+`, `-`, `*`, `/`, `<`, `>`, `=`, `<>`, etc. all resolve to their `i.*` counterparts when written bare, but `pow` does not. ## Reproduction ```seq : test-plus ( -- ) 3 4 + 7 test.assert-eq ; # ✓ resolves : test-lt ( -- ) 3 4 < true test.assert ; # ✓ resolves : test-pow ( -- ) 2 3 pow # ✗ Unknown word: 'pow' 8 test.assert-eq ; ``` Run `seqc lint` on the third — error: ``` error [type-error]: Unknown word: 'pow' ``` The first two compile fine (modulo unrelated `i./` Bool-flag bookkeeping for the `/` case). ## Expected `pow` should resolve to `i.pow` with the same `( Int Int -- Int Bool )` signature — matching how `/` resolves to `i./` and keeps the Bool flag from `i.modulo`/`i.divide`. ## Why this matters Seq's design choice (per `docs/language-guide.md`) is that `i.` prefixes are *required* on the canonical word names but bare arithmetic/comparison ops resolve via implicit sugar. The sugar is undocumented in the language guide but it's clearly present (the examples above prove it). When `i.pow` was added, the sugar table wasn't updated alongside, leaving `pow` as an outlier among the arithmetic ops. Knock-on effect: seqlings chapter 27 (the `std:imath` chapter) has an exercise that asks the student to type `2 10 pow` — which mirrors the docs in `STDLIB_REFERENCE.md` and the surrounding sugar conventions, but doesn't compile. ## Suggested fix Wherever the bare-name sugar table for integer ops lives, add `pow → i.pow`. If the language-guide doc-bug (sugar table not documented) is in scope, that's worth fixing in the same PR — currently a reader has to discover the sugar empirically.

navicore added the

bug

label

2026-05-18 22:51:03 +00:00

navicore self-assigned this

2026-05-18 22:51:05 +00:00

navicore commented

2026-05-18 22:57:21 +00:00

Author

Owner

What the design doc says

docs/design/done/INT_POW_BUILTIN.md:22-23 is explicit:

▎ No alias, no shim. The stdlib pow in imath.seq is deleted in the same commit; callers move to i.pow.

That was a deliberate v7.0 decision, not a forgotten-update bug. And docs/language-guide.md:1018-1021 documents
the convention: i. prefixes are required on named forms; only the symbolic forms get sugar.

Verdict

Real bug? No. The behavior matches the documented language design and the design doc that introduced i.pow.
Oversight in the sugar? Also no — adding pow → i.pow without also adding add, subtract, divide, modulo, eq,
lt, etc. would introduce an inconsistency rather than fix one. Adding all of them is a much larger design change
(and contradicts the explicit "named ops require i." guidance in the language guide).
What's real: the seqlings ch. 27 exercise the issue mentions has a typo (2 10 pow should be 2 10 i.pow).
That's a seqlings fix, not a compiler fix.

If you wanted to do anything here, the smallest defensible move would be a better error message for bare
pow/add/eq/etc. — something like Unknown word: 'pow' — did you mean 'i.pow'? — rather than introducing new
sugar.

What the design doc says docs/design/done/INT_POW_BUILTIN.md:22-23 is explicit: ▎ No alias, no shim. The stdlib pow in imath.seq is deleted in the same commit; callers move to i.pow. That was a deliberate v7.0 decision, not a forgotten-update bug. And docs/language-guide.md:1018-1021 documents the convention: i. prefixes are required on named forms; only the symbolic forms get sugar. Verdict - Real bug? No. The behavior matches the documented language design and the design doc that introduced i.pow. - Oversight in the sugar? Also no — adding pow → i.pow without also adding add, subtract, divide, modulo, eq, lt, etc. would introduce an inconsistency rather than fix one. Adding all of them is a much larger design change (and contradicts the explicit "named ops require i." guidance in the language guide). - What's real: the seqlings ch. 27 exercise the issue mentions has a typo (2 10 pow should be 2 10 i.pow). That's a seqlings fix, not a compiler fix. If you wanted to do anything here, the smallest defensible move would be a better error message for bare pow/add/eq/etc. — something like Unknown word: 'pow' — did you mean 'i.pow'? — rather than introducing new sugar.

navicore closed this issue

2026-05-18 22:57:21 +00:00