Skip to content

[codex] add logical OR support#57

Draft
thiremani wants to merge 13 commits into
masterfrom
codex/add-logical-or-support
Draft

[codex] add logical OR support#57
thiremani wants to merge 13 commits into
masterfrom
codex/add-logical-or-support

Conversation

@thiremani
Copy link
Copy Markdown
Owner

Summary

  • Add || as a logical OR operator distinct from bitwise |.
  • Support || in statement conditions with scalar I1 OR lowering.
  • Support value-position || as left-biased conditional fallback, including plain fallback values such as a < 5 || 10.

Validation

  • python3 test.py tests

thiremani added 13 commits May 3, 2026 23:13
Add || parsing and typing for statement conditions and value-position conditional expressions. In value position, logical OR now preserves Pluto's conditional value semantics by returning the first admitted value and supporting plain fallback values when the left condition fails.

Covers parser behavior, bitwise OR non-regression, scalar/function-argument fallback, ranged array fallback, and ranged condition gates in E2E tests.
Rename the OR fallback lowering path around its onTrue/onFalse contract, share scalar comparison extraction, and gate base conditions once before entering OR fallback selection.

Add E2E coverage for heap-string fallback, tuple fallback, and nested value-position OR expressions.
Lower boolean-position || through explicit branching instead of the eager scalar operator table. Tighten the conditional LHS binding invariant, move the i1 predicate alongside type helpers, and add condition-gate regression coverage for RHS skipping.
Add parser and E2E coverage for expressions where || appears in both the statement condition and value expression. Remove defensive internal panics that were not needed for normal logical OR lowering.
Document why value-position || accepts a conditional left operand with a fallback right operand, and why the language does not add a matching && form in this PR.
Rename ExprInfo.HasCondOr to HasFallbackOr so boolean logical OR dispatch reads in terms of fallback-OR semantics rather than the internal CondOr lowering mode.
Remove redundant arity panics from boolean logical OR lowering; the solver already rejects multi-output operands before compilation.
Remove a defensive nil check in fallback OR detection; compiler lowering already assumes typed expressions are present in ExprCache.
Add ast.IsLogicalOr and use it at AST-expression logical OR checks so compiler conditional lowering does not import token just to inspect operator spelling.
Use InfixExpression.IsLogicalOr when callers already have an infix node, while keeping ast.IsLogicalOr for arbitrary expression checks.
Collapse the WithFailure variant into compileCondExprBranch by making the false continuation explicit at each call site.
Rename extractCondExprSelf to extractInfixCondExpr to distinguish recursive expression-tree extraction from extracting one infix comparison node.
Rename conditional OR token/parser labels and shorten the fallback-yield lowering helpers so the control flow is easier to follow. Keep comments focused on ownership and value-position behavior rather than restating helper names.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant