MQ-1: a positional fold step lowers like the named form (position from std.algebra's fold signature)

[gunbai-bot]

MQ-1: a positional fold step lowers like the named form

fold(xs, 0, fn(acc, y) { .. }) never lowered. v2.compiler.fold_lowering fold_call_step_form found the step only by NAME (^f), so the positional spelling became StepByName. fold stayed an ordinary call, and resolve refused it with resolve_reason_unbound_symbol. Real sites that use this spelling: dag/extdeps/container/oci/linux.dag contains_namespace_type and four calls in dag/gunbc/instruments/rust_stage0_gates.dag.

The step's position comes from the primitive's declared signature

• std.algebra collection_fold_shape. The two identical fold rows (free_monoid_collection and pointwise_power_collection) are now one template, like collection_filter_shape. It gains the ReceiverSelf slot that every sibling row (map, filter, any, ...) already carries, so param_types is the full free-call signature, receiver first.
• template_step_position reads the first callable parameter's index off a template. fold_lowering fold_step_argument_position takes the position from that function. No literal index is written anywhere.
• v2.extdeps.languages.dag dag_call_positional_arg_value_optional reads the direct argument at a position. It uses the same stop-at-every-arg rule as the named lookup, and a named argument at that position answers Absent.
• fold_call_step_form tries the name first, then the declared position. Both spellings reach the same step node and lower through the one seam. No second path was added.

Parameter names. The row carries no parameter NAMES, so the names (^f, ^cons, ^snoc, ^algebra) stay authored per head in fold_step_argument_name. That is stated at the site.

Census of fold-family members

head	name	position
fold	^f	from collection_fold_shape
fold_list, fold_list_right, fold_node	^cons / ^snoc / ^algebra	frontier: name-only

Their signatures are ordinary v2 fn declarations with no data projection this stage can read, and no positional call site of any of them exists (§3c). A positional one stays the counted FoldCallStepFormUnresolved state until those signatures become readable here.

v1 consumers of the changed template, with behaviour unchanged

Adding ReceiverSelf to the fold row is admitted under v1_seed_standing because it serves v2 and corrects the row. The v1 readers of param_types are:

• v1.compiler.types build_type_substitution strips a leading ReceiverSelf.
• v1.compiler.lookup declared_arg_types_for_method strips a leading ReceiverSelf.
• v1.compiler.types instantiate_algebra_field builds the same Self-first field shape map already has.
• v1.compiler.method algebra_param_templates: fold has no derived_signature registry row, so nothing pairs names against it.
• callback_element_position indexes inside the callable, so it is unchanged.

The stage0 mirror std_algebra.rs was regenerated with --required-regen and the candidate installed. On the rebuilt binary:

• dag/test/claim/primitive_signature_grounding_witness_test.dag: 11/11 pass.
• method_arg_declared_contract_witness_test: red. It is already enrolled expected-red (floor_expected_red, quarantined in gunbc.explicit_witness_admission), and its subject is get, not fold.
• cargo test --release -p v1-compiler --lib (local only, since rust_unit_tests_off_the_merge_path takes it off CI): 10 failures on this head, all 10 also failing on the base commit (MQ-1: function values in value position (lambdas and fn literals) lower to the generic fn Arrow; unwritten types are fresh type parameters #12210's head, same host). The baseline run reported 950 passed / 30 failed. That count is inflated by the base worktree being removed mid-run, which can only add failures, never hide one. No test newly fails. None of the 10 reads the algebra fold template.
• The regen fixed point was not re-run after the install; merge_group's build lane runs it.

Controls

• v2.test.claim.fold_lowering positional_fold_step_lowers_to_the_named_forms_loop: the positional form's lowered Loop has the same content_hash as the named form's.
• Mutation: reverting fold_call_step_form to name-only (Absent => StepByName) turns that claim red (FAIL), while well_formed_fold_still_lowers_through_the_split stays green.
• positional_named_step_fold_is_step_form_unresolved: fold(xs, 0, step) stays unresolved. The positional reading does not widen into accepting whatever sits in the slot.
• All 18 claims in the module pass locally.

The expected-red row does not retire (split ruled by gentle-koi-724)

wave1_gate1_b1_builtin_call_resolves_end_to_end_witness_holds no longer hits the unbound-fold refusal. Measured with gunbc run over a probe of conserved_normalize_of_text → resolve on the fixture:

positional fold(x, 0, fn(acc, _) { acc })          -> normalize: conservation_reason_dropped_reference
named      fold(x, init: 0, f: fn(acc, _) { acc }) -> normalize: conservation_reason_dropped_reference
bare-call control                                   -> ok

The two forms now fail identically, at the next boundary: fold_call_seam_loop builds Loop(body, bound, carrier) and carries neither the collection nor init. The row (renamed floor_expected_red_chunk_fold_seam_loop_drops_operands) restates that cause.

• Owner: MQ-5 (gentle-koi-724 lane).
• Trigger: the fold seam Loop carries collection and init, conserved.

Consumers of the Loop contract that the fix must migrate:

• v2.std.node loop_behavior_edges_conform / loop_body_edges_conform close the Loop's named edges to exactly ^loop_bound_edge and ^loop_carrier_edge. New operand edges must be admitted there.
• v2.std.node loop_carrier_binder_target
• v2.std.cardinality loop_multiplicity, which reads the bound
• v2.lens.complexity_accumulator_copy.analyze, which reads the carrier off fold_call_to_loop and gates on fold_family_head
• v2.compiler.body_lowering_fold body_lower_try_fold_loop

Frontier, not this slice: option (b)

Resolve binding primitive callees from std.primitive_identity. After this PR, fold in any spelling with an inline step no longer reaches resolve as a callee. Primitive callees that still reach resolve outside fold_lowering:

• fold with a step passed by name (fold(xs, 0, step))
• every other roster primitive called as a free function (map, filter, flat_map, any, all, count, length, contains, ...), since fold_lowering handles only the fold family

Based on session/fierce-gull-556 (#12210), which owns the row and the shared step-literal decoder.

🤖 Generated with Claude Code

[gunbai-bot]

Re review 71734 (src/v2/std/anonymous_binder.dag is_fresh_type_variable has no caller): confirmed. git grep finds only its definition. It is not part of this PR's change: it arrives with #12210 (commit 0d3c75e, the structural-path fresh type variables), which this branch is stacked on, and this branch's copy of that file is identical to #12210's. The fix belongs on #12210, so I've sent the finding to its author (fierce-gull-556) and will pick up the deletion or the wired-in reader on the next merge from #12210. This PR's own seven files are dag/std/algebra.dag, src/v1/stage0/src/std_algebra.rs, src/v2/compiler/fold_lowering.dag, src/v2/extdeps/languages/dag.dag, src/v2/test/claim/fold_lowering_test.dag, src/v2/workflow/floor_expected_red.dag and src/v2/workflow/floor_pure_producer_share.dag.

— sent from merry-hawk-532

[gunbai-bot]

Re review 71746 (fresh_type_variable packs its path and label into a Symbol spelling, and is_unpositioned_fresh_type_variable parses them back by prefix): this code is not part of this PR's change. src/v2/std/anonymous_binder.dag and the body_lowering_fold.dag call sites arrive with #12210 (its structural-path fresh type variables), and this branch's copies are identical to #12210's head. The fix belongs on #12210. I've sent the finding to its author (fierce-gull-556) with your suggested fix: a typed carrier, or naming this encoding in type_variable_identified_by_spelling_in_v2 with a capability trigger. I'll pick it up on the next merge from #12210.

— sent from merry-hawk-532

[briansrls]

Verdict: APPROVE e2f97bb

Independent exact-head review, not a proxy acceptance of dashboard review 72020. No blocking finding in MQ-1. collection_fold_shape replaces both duplicate collection templates; its ReceiverSelf-first param_types supplies the step position through template_step_position rather than a literal offset. I checked declared_arg_types_for_method and build_type_substitution at this head: both remove a leading ReceiverSelf before pairing ordinary method arguments, so adding that slot does not shift those consumers' init/step contract. The Rust delta is the generated form of the .dag template/reader change, not an undeclared handwritten rule.

The positional reader counts each direct arg once and stops at that arg rather than searching inside its value; a named actual in that source position is not reclassified as positional. Named and positional lookup converge on the same fold_step_form_at and existing function-value reader. A positional step that is a reference remains FoldCallStepFormUnresolved. The named-only frontier for fold_list/fold_list_right/fold_node is explicit rather than inferred to work from fold's row.

The current diff does not restore chunk_15 or the retired #12210 rows. Its one expected-red rename describes the still-observed reference-conservation failure, with MQ-5 owning the capability to carry collection and init in the Loop. Reaching fold lowering is not an end-to-end passing fold; this approval does not call it one.

I credit the reported 18 passing fold claims, named-only mutation failing positional parity while the named positive stays green, and the 11 primitive-signature claims. I do not credit a complete Rust-suite base/head equivalence measurement: the body says the base worktree was removed during that run, so the absence of newly listed failures is weaker evidence than a controlled completed comparison. The source consumer trace and the targeted controls are the evidence used here. Exact-head workflow 36368968596 succeeded; fixed-point enforcement remains on the merge-group route. No local rerun performed by this reviewer.

GitHub currently reports this branch non-mergeable. Conflict repair or a main merge changes the head and requires a delta review before enqueueing.

[briansrls]

Correction to review 5338362885's mergeability note: I found that the normalized PR summary can turn GitHub's unknown mergeability result into false. I have not established a conflict on this branch and withdraw the statement that conflict repair is required. Do not re-merge solely because of my note; confirm GitHub's completed mergeability result. The independent APPROVE at e2f97bb and its stated evidence/operand-conservation limits remain unchanged.