`ends with` / `starts with` operators are swallowed as multi-word identifiers at statement level

[logbie]

Summary

X ends with "…" and X starts with "…" do not work reliably in a check if
condition at statement level. The parser's multi-word–identifier rule absorbs the
operator keyword, lexing path ends with ".css" as the identifier path ends
followed by with ".css". The program then fails semantic analysis with
Variable 'path ends' is not defined (and analogously for starts).

There is no dedicated lexer token for these operators — the lexer only defines
KeywordContains (src/lexer/token.rs), not ends/starts — so they are not
parsed as operators at all in this position.

Reproduction (release build)

store path as "/style.css"
check if path ends with ".css":
    display "css"
otherwise:
    display "no"
end check

error[ANALYZE-SEMANTIC]: Variable 'path ends' is not defined

Same failure for check if path starts with "/style": → Variable 'path starts' is not defined.

contains works correctly as contains of X and Y, and the 3-argument
substring of X and 1 and length of X works; only the starts with / ends with
infix forms are affected.

Why this is easy to miss

Several existing programs contain these forms — e.g.
TestPrograms/comprehensive_web_server_demo.wfl uses both
request_path starts with "/static/" and file_path ends with ".css". They pass
--parse and survive --analyze (which is lenient here), so they look supported,
but they fault under the full pipeline. The forms also appear in user-facing docs.

Impact

• Prefix/suffix string matching — a very common need, especially for web-server
  request routing — silently breaks or misleads users.
• Docs and demo programs imply these operators work when they do not end-to-end.

Suggested fix

Give starts with / ends with real operator support — either dedicated
KeywordStartsWith / KeywordEndsWith tokens, or a proper infix parse that binds
before multi-word identifier accumulation — mirroring how contains is handled.
Add TestPrograms covering both operators under the full pipeline so regressions are
caught (the current demo usages only exercise --analyze).

Notes

Found while drafting the route construct design (PR #565), where prefix/suffix
when heads depend on these operators. Context and validated interim workarounds
are documented in Docs/development/route-construct-design.md.

[logbie]

Assessment: confirmed bug (lexer/parser).

Verified: src/lexer/token.rs defines #[token("contains")] KeywordContains (line ~234) but has no token for starts/ends (or starts with/ends with). With no operator token, the multi-word-identifier accumulator greedily absorbs path ends as one identifier, leaving with "…" dangling — so the analyzer reports Variable 'path ends' is not defined, exactly as in your repro. contains avoids this only because it has a real token.

Fix shape: give the two operators real tokens (e.g. KeywordStartsWith/KeywordEndsWith, or KeywordStarts/KeywordEnds) and an infix parse that binds before multi-word-identifier accumulation, mirroring the KeywordContains handling (note token.rs already special-cases KeywordContains so it can still be used as a function name at line ~631 — the new tokens likely need the same treatment). Backward-compatibility: these forms currently fail end-to-end, so adding support only fixes them — but please audit the multi-word-identifier path so ordinary identifiers that merely contain "starts"/"ends" aren't newly broken. Add TestPrograms/ coverage that runs both operators under the full pipeline, not just --analyze — the existing demo usages (comprehensive_web_server_demo.wfl) only survive --analyze, which is precisely why this slipped through. Suggested labels: bug, parser.

Posted by the WFL repo warden (automated triage pass).

[logbie]

Fixed on branch claude/github-issues-review-i7upri.

Added KeywordStarts/KeywordEnds lexer tokens (so the multi-word identifier accumulator no longer swallows path ends), marked contextual so they can still be used as names, plus an infix parse in binary.rs at comparison precedence that desugars X starts with Y / X ends with Y to the existing starts_with/ends_with builtins — no new interpreter/type-checker operator needed. The route construct's when starts with / when ends with arms were switched to the new tokens. Added full-pipeline TestPrograms-style coverage (positive, negative, and stored-boolean forms) in tests/github_issues_batch_test.rs; route_comprehensive.wfl and the web-server demos that use these forms still pass.

---

Generated by Claude Code

[logbie]

Status: verified merged on main — recommend closing.

The earlier note here said the fix was on branch claude/github-issues-review-i7upri, but that branch was never confirmed after it landed. It did land: PR #587 ("Fix five GitHub issues: string coercion, parameter shadowing, operators, scope, typing") merged as commit 2c52826.

Evidence on current main:

• src/lexer/token.rs now defines KeywordStarts (line 243) and KeywordEnds (line 245), so starts with / ends with are lexed as operator tokens instead of being swallowed into a multi-word identifier. src/parser/expr/binary.rs gained the corresponding binary-expression handling.
• The token list that decides "operator vs. name" at statement level was updated to include Token::KeywordStarts, which is exactly the statement-level context this issue reported.
• Regression tests are locked in at tests/github_issues_batch_test.rs: starts_with_operator_in_check, ends_with_operator_in_check, starts_ends_with_negative_cases, and ends_with_stores_boolean_result. These run in the Integration Tests job and are green on main.

No residual work that I can see. Closing this out is just bookkeeping.

Posted by the WFL repo warden (automated triage pass).

[logbie]

Verified fixed on WFL 26.7.36 (fc21f2f, Linux release build) during the #610 Phase 1 open-issue inventory.

Fixed by PR #587 — added contextual KeywordStarts/KeywordEnds tokens with an infix parse at comparison precedence that desugars to the existing starts_with/ends_with builtins.

Repro from this issue now runs clean:

$ wfl repro.wfl
css
starts-ok
[exit 0]

Both path ends with ".css" and path starts with "/sty" evaluate correctly in check if conditions; no more Variable 'path ends' is not defined. Closing as completed.

---

Generated by Claude Code