Reserved words can't be used as SHOW_PAGE parameter names

[ako]

Description

When a page parameter is named with a reserved keyword (e.g., `Operation`), the colon syntax fails to parse:

-- Fails: Operation is a reserved keyword
SHOW_PAGE MES.Operation_NewEdit(Operation: \$currentObject)

The grammar rule `showPageArg` uses `identifierOrKeyword` which should accept keywords, but in practice the parser fails — likely due to ANTLR ambiguity with the specific token sequence.

Workaround

Use the `$Param = $value` syntax instead:

SHOW_PAGE MES.Operation_NewEdit(\$Operation = \$currentObject)

Suggested Fix

Either fix the parsing ambiguity so `identifierOrKeyword` works reliably in parameter positions, or support quoted identifiers (`"Operation": $value`) consistently.

Impact

Low — workaround exists, but it's not discoverable without trial and error.

[github-actions]

Issue Triage

Summary:
The issue reports that using a reserved keyword (e.g., Operation) as a parameter name in a SHOW_PAGE call causes a parsing failure, while the $Param = $value syntax works as a workaround.

Checklist for bug report completeness

Required info	Present?	Notes
mxcli version	❌	Not mentioned
Mendix version	❌	Not mentioned
Scenario (what the user was trying to do)	⚠️ Partially	Indicates using SHOW_PAGE in an MDL script, but no explicit CLI command or context
Expected output	❌	Not stated (what should happen when the parameter is used)
Experienced output	❌	Not stated (no error message, crash details, or wrong result)
AI bug report (session log or mxcli diag --bundle)	❌	Not provided

Polite request for missing information
Thanks for reporting this! To help us investigate, could you please add:

1. The version of mxcli you’re using (mxcli --version or commit/build info).
2. The Mendix version of the project you’re processing (e.g., 10.6, 9.24).
3. The exact CLI command or MDL script you ran when the issue occurred.
4. What you expected to happen (e.g., the page opens with the parameter passed).
5. The actual error or output you saw (copy‑paste any error message, crash trace, or wrong result).
6. If possible, the output of mxcli diag --bundle or at least the session log.

Once we have those details, we’ll be able to reproduce and fix the problem. Thanks again!

---

Automated triage via OpenRouter — workflow source

[ako]

Resolved (verified empirically, fix landed)

The reported case already works on current main: showPageArg uses identifierOrKeyword, which accepts both bare keywords and quoted names — so all of these parse and pass mxcli check:

show page M.Operation_NewEdit (Operation: $obj);    -- bare keyword arg  ✓
show page M.Operation_NewEdit ("Operation": $obj);  -- quoted arg        ✓
show page M.Operation_NewEdit ($Operation = $obj);  -- canonical form    ✓

The ANTLR ambiguity this issue described is gone.

The one residual gap (now fixed)

The page/snippet parameter declaration accepted only (IDENTIFIER | VARIABLE), so a bare reserved-word name failed:

Params: { List: M.Order }   -- extraneous input 'List' expecting ':'

The $-prefixed form (Params: { $List: M.Order }) always worked, and DESCRIBE emits params $-prefixed — so DESCRIBE output was already roundtrip-safe. For parity with the widget-name fix (#619), pageParameter/snippetParameter now also accept QUOTED_IDENTIFIER, and the visitor unquotes it:

Params: { "List": M.Order }       -- page    ✓
Params: { "Template": M.Order }   -- snippet  ✓

Fix

• Grammar: pageParameter / snippetParameter accept QUOTED_IDENTIFIER.
• Visitor: the three param-name sites unquote a quoted name.
• Tests: page + snippet quoted-reserved-param parse tests; bug-test mdl-examples/bug-tests/114-quoted-reserved-page-params.mdl.

Closing as resolved. Remaining strict-IDENTIFIER positions of the same class (e.g. security read(...)/write(...) member lists) are tracked alongside #619.