README.md (1)

653-653: Consider using explicit builtin names in the Collections row.
Using array_map, array_filter, array_fold, and array_slice here would remove ambiguity about whether these are methods or standalone built-ins.

Suggested wording tweak

-| Collections | `Array<T>` with `map`, `filter`, `fold`, `slice` | Functional iteration — no mutation, no loop constructs |
+| Collections | `Array<T>` with `array_map`, `array_filter`, `array_fold`, `array_slice` | Functional iteration — no mutation, no loop constructs |

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@README.md` at line 653, The Collections row currently lists `map`, `filter`,
`fold`, `slice` which is ambiguous about whether they are methods or standalone
builtins; update that row to use explicit builtin names like `array_map`,
`array_filter`, `array_fold`, and `array_slice` so readers know these are
top-level functions (refer to the table row labeled "Collections" and the items
`map`, `filter`, `fold`, `slice` for the exact place to change).

tests/test_codegen_monomorphize.py (1)

704-897: Add coverage for generic type-shape behaviour and fold argument order.
The suite validates happy paths well, but it does not yet lock in two core semantics: (1) array_map changing element type, and (2) fold callback argument order on a non-commutative operation.

Proposed test additions

 class TestArrayOperations:
@@
+    def test_array_map_type_change(self) -> None:
+        """Map Int -> String changes element type."""
+        source = """\
+public fn main(-> `@Bool`)
+  requires(true) ensures(true) effects(pure)
+{
+  let `@Array`<String> = array_map([1, 2], fn(`@Int` -> `@String`) effects(pure) { to_string(`@Int.0`) });
+  eq(`@Array`<String>.0[1], "2")
+}
+"""
+        assert _run(source, fn="main") == 1
+
+    def test_array_fold_order_non_commutative(self) -> None:
+        """Fold callback order is (acc, elem), left-to-right."""
+        source = """\
+public fn main(-> `@Int`)
+  requires(true) ensures(true) effects(pure)
+{
+  array_fold([1, 2, 3], 0, fn(`@Int`, `@Int` -> `@Int`) effects(pure) { `@Int.1` * 10 + `@Int.0` })
+}
+"""
+        assert _run(source, fn="main") == 123

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@tests/test_codegen_monomorphize.py` around lines 704 - 897, Add tests
covering (1) array_map changing element type and (2) array_fold argument order
for non-commutative ops: add a test that uses array_map to transform Int->Bool
(e.g., map [1,2,3] to [true/false] and assert type-shaped behavior or element
values) referencing array_map and assert result indexing/length, and add a test
for array_fold where the fold callback distinguishes accumulator vs element
order (e.g., subtract or concatenate with order-sensitive operation) referencing
array_fold and asserting the exact numeric/string result to lock in the callback
argument order.

tests/test_prelude.py (1)

69-70: Prefer name-based assertions over raw declaration-count checks.
These assertions are fragile and can mask incorrect injection content.

Suggested assertion hardening

-        # 9 array declarations: 3 type aliases + 6 functions
-        assert len(prog.declarations) == orig_len + 9
+        fn_names = {
+            tld.decl.name
+            for tld in prog.declarations
+            if isinstance(tld.decl, ast.FnDecl)
+        }
+        alias_names = {
+            tld.decl.name
+            for tld in prog.declarations
+            if isinstance(tld.decl, ast.TypeAliasDecl)
+        }
+        assert {
+            "array_map", "array_map_go",
+            "array_filter", "array_filter_go",
+            "array_fold", "array_fold_go",
+        }.issubset(fn_names)
+        assert {"ArrayMapFn", "ArrayFilterFn", "ArrayFoldFn"}.issubset(alias_names)
+        assert "option_map" not in fn_names
+        assert "result_map" not in fn_names
@@
-        # Only array declarations injected (9), not Option combinators
-        assert len(prog.declarations) == orig_len + 9
+        fn_names = {
+            tld.decl.name
+            for tld in prog.declarations
+            if isinstance(tld.decl, ast.FnDecl)
+        }
+        assert {
+            "array_map", "array_map_go",
+            "array_filter", "array_filter_go",
+            "array_fold", "array_fold_go",
+        }.issubset(fn_names)
+        assert "option_unwrap_or" not in fn_names
+        assert "option_map" not in fn_names
+        assert "option_and_then" not in fn_names

Also applies to: 85-86

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@tests/test_prelude.py` around lines 69 - 70, The test currently asserts a
fragile raw count on prog.declarations; instead replace the length checks with
name-based assertions that ensure the specific 3 type-alias names and 6 function
names were injected into prog.declarations. Locate the checks that use
prog.declarations (the count assertion around the "9 array declarations" and the
similar assertion at the later block) and assert presence by collecting
declaration names from prog.declarations and comparing against an expected set
of declaration names (or asserting each expected name exists) so the test
verifies exact injected symbols rather than just a length.

ROADMAP.md (2)

35-35: Incomplete operation list in the Tier 1 ASCII diagram.

The diagram entry "#133 map/fold" only mentions 2 of the 4 delivered operations (map and fold), omitting filter and slice. For consistency with lines 50 and 58 which list all four operations, consider:

• Using "array ops" (matching the Tier 0 entry on the same line), or
• Expanding to "map/fold/filter/slice" if space permits.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@ROADMAP.md` at line 35, The Tier 1 ASCII diagram currently lists "#133
map/fold" but omits the other delivered operations; update that entry (the text
"#133 map/fold") to either "✓ `#133` array ops" to match the Tier 0 wording or
expand it to "✓ `#133` map/fold/filter/slice" so all four operations are listed
(locate the string "#133 map/fold" in ROADMAP.md and replace accordingly).

---

21-21: Clarify whether the counts are cumulative or overlapping.

The phrasing "72 built-in functions plus 5 Option/Result combinators plus 4 higher-order array operations" is ambiguous about whether these counts overlap. Consider either:

• "72 built-in functions (including 5 Option/Result combinators and 4 array operations)" if 72 is the total, or
• "68 built-in functions plus 5 Option/Result combinators plus 4 higher-order array operations (77 total)" if they're separate counts.

Based on the 68 → 72 increment matching the 4 new array operations, the former interpretation appears correct.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@ROADMAP.md` at line 21, The statement under v0.0.91 in ROADMAP.md is
ambiguous about whether "72 built-in functions plus 5 Option/Result combinators
plus 4 higher-order array operations" are overlapping counts; update that
sentence (the v0.0.91 release description) to explicitly state the intended
interpretation—for example, "72 built-in functions (including 5 Option/Result
combinators and 4 higher-order array operations)" if 72 is the total, or
alternatively list each as a separate subtotal and include the total sum—so
readers know whether the combinators and array ops are included in the 72 or are
additional.

vera/codegen/monomorphize.py (1)

529-539: Consider adding strict=True to zip for defensive programming.

While the invariant that forall_vars and concrete_types have equal length is maintained by the call chain, adding strict=True would catch any future regression and make the assumption explicit.

♻️ Optional improvement

         assert decl.forall_vars is not None
-        mapping = dict(zip(decl.forall_vars, concrete_types))
+        mapping = dict(zip(decl.forall_vars, concrete_types, strict=True))
         mangled = self._mangle_fn_name(decl.name, concrete_types)

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@vera/codegen/monomorphize.py` around lines 529 - 539, The zip between
decl.forall_vars and concrete_types should be made strict to fail fast on length
mismatches: when building mapping = dict(zip(decl.forall_vars, concrete_types))
update it to use zip(..., strict=True) so any future mismatch between
decl.forall_vars and concrete_types is caught; the change affects the code path
that computes mapping used by _mangle_fn_name, _build_reindex_map, and
_substitute_in_ast.

vera/wasm/inference.py (1)

457-479: LGTM with optional improvement.

The closure return type inference logic is sound. The length check on lines 465–467 ensures the zip on line 469 is safe. However, adding strict=True would make the intent explicit and catch any future regression if the guard is accidentally removed.

♻️ Optional: add `strict=True` for clarity

-                        alias_map = dict(zip(alias_params,
-                                             closure_arg.type_args))
+                        alias_map = dict(zip(alias_params,
+                                             closure_arg.type_args,
+                                             strict=True))

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@vera/wasm/inference.py` around lines 457 - 479, The zip used to build
alias_map in the apply_fn closure inference should be made explicit/strict to
ensure lengths are enforced; update the dict(zip(alias_params,
closure_arg.type_args)) call inside the apply_fn handling (where alias_params
and closure_arg.type_args are checked and alias_map is created) to use
strict=True so any future removal of the length guard will raise if lengths
differ, leaving the surrounding checks (closure_arg, alias_te, alias_params)
unchanged.

vera/wasm/calls.py (2)

1001-1005: ⚠️ Potential issue | 🟠 Major

_infer_concat_elem_type still rejects array_map(...) results.

This helper now knows about array_slice and array_filter, but array_slice(array_map(xs, f), ...) still bottoms out at Line 845 and returns None. Please derive Array<T> from the expression's inferred return type here, or handle array_map explicitly, so the new array combinators actually compose.

🔧 Fix sketch

     def _infer_concat_elem_type(self, expr: ast.Expr) -> str | None:
+        arg_info = self._get_arg_type_info_wasm(expr)
+        if arg_info and arg_info[0] == "Array" and arg_info[1]:
+            return arg_info[1][0]
+
         if isinstance(expr, ast.SlotRef):
             if expr.type_name == "Array" and expr.type_args:
                 ta = expr.type_args[0]
                 if isinstance(ta, ast.NamedType):
                     return ta.name
@@
         if isinstance(expr, ast.FnCall):
             if expr.name == "array_range":
                 return "Int"
             if expr.name in (
                 "array_concat", "array_append", "array_slice",
                 "array_filter",
             ) and expr.args:
                 return self._infer_concat_elem_type(expr.args[0])

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@vera/wasm/calls.py` around lines 1001 - 1005, The branch that returns
self._infer_concat_elem_type(expr.args[0]) for array combinators (expr.name in
("array_concat","array_append","array_slice","array_filter")) fails when the arg
is an array-producing call like array_map; update this logic in the function
handling expr.name to either (A) if expr.args[0] is a call expression (e.g.
expr.args[0].name == "array_map") handle it explicitly by extracting the mapped
element type (using the map's return type), or (B) more generally obtain the
inferred return type of expr.args[0] and, if it is an Array<T>, derive and
return T; ensure this uses the existing _infer_concat_elem_type helper and any
available type inference routine so array_slice(array_map(...)) and
array_filter(array_map(...)) correctly yield the inner element type instead of
None.

---

876-921: ⚠️ Potential issue | 🟠 Major

Clamp indices in i64 space before wrapping.

Line 876 and Line 881 still truncate the user-supplied Int indices before any bounds check. Values like 1 << 33 will wrap into unrelated i32 values, so the later clamp can produce the wrong slice instead of clamping to the array bounds.

🔧 Fix sketch

-        # Evaluate start → i64, wrap to i32
-        instructions.extend(start_instrs)
-        instructions.append("i32.wrap_i64")
-        instructions.append(f"local.set {s}")
-
-        # Evaluate end → i64, wrap to i32
-        instructions.extend(end_instrs)
-        instructions.append("i32.wrap_i64")
-        instructions.append(f"local.set {e}")
+        s64 = self.alloc_local("i64")
+        e64 = self.alloc_local("i64")
+
+        # Evaluate start/end as i64 first
+        instructions.extend(start_instrs)
+        instructions.append(f"local.set {s64}")
+        instructions.extend(end_instrs)
+        instructions.append(f"local.set {e64}")
+
+        # Clamp start/end against 0 and arr_len while still in i64,
+        # then wrap once the values are known to be in range.
+        ...
+        instructions.append(f"local.get {s64}")
+        instructions.append("i32.wrap_i64")
+        instructions.append(f"local.set {s}")
+        instructions.append(f"local.get {e64}")
+        instructions.append("i32.wrap_i64")
+        instructions.append(f"local.set {e}")

In WebAssembly, does `i32.wrap_i64` truncate the upper 32 bits rather than clamp, and should user-supplied `i64` indices be range-checked before wrapping to `i32`?

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@vera/wasm/calls.py` around lines 876 - 921, The code currently uses
i32.wrap_i64 on start/end before clamping which truncates 64-bit indices; change
the flow to perform all bounds checks and clamps in i64 space first (use
i64.const 0, i64.lt_s, i64.gt_s and compare against arr_len promoted to i64),
ensure "Clamp start" and "Clamp end" logic operates on i64 values (variables
referenced as start_instrs, end_instrs, s, e, arr_len), then call i32.wrap_i64
only after the final clamped i64 values and set the i32 locals; adjust the
generated instructions accordingly so no wrapping happens prior to range checks.

vera/wasm/inference.py (1)

569-574: Keep bare Array handling consistent across the helper predicates.

This branch now treats bare Array as pair-like, but _is_array_type_name() on Lines 560-562 still returns False for the same string. That means callers can now get different answers for the erased array representation depending on which helper they consult.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@vera/wasm/inference.py` around lines 569 - 574, The helper predicates are
inconsistent: one treats bare "Array" as an array but _is_array_type_name(...)
still returns False for "Array"; update _is_array_type_name to also return True
when type_name == "Array" (in addition to existing checks like
type_name.startswith("Array<")), so both _is_array_type_name and the pair-like
predicate (the function that currently checks type_name == "Array" or
type_name.startswith("Array<")) agree on the erased array representation.

README.md (1)

587-587: ⚠️ Potential issue | 🟡 Minor

Use “GitHub CI” as the link label for naming consistency.

Line [587] still uses [CI](.github/workflows/ci.yml). Please rename the visible label to GitHub CI while keeping the same target URL.

Suggested wording tweak

-... enforced by pre-commit hooks and [CI](.github/workflows/ci.yml) ...
+... enforced by pre-commit hooks and [GitHub CI](.github/workflows/ci.yml) ...

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@README.md` at line 587, Update the README link label from "CI" to "GitHub CI"
while keeping the same target URL (.github/workflows/ci.yml); locate the
markdown snippet in README.md that reads `[CI](.github/workflows/ci.yml)` and
replace the visible text to `[GitHub CI](.github/workflows/ci.yml)` so the link
target is unchanged but the label matches the project naming convention.