[revisit]Not implemented yet{@If} conditionally adds a section to a pattern or replacement based on the condition

Assuming that x is defined numeric value,

Pattern: Testing {@If(x > 5): this and } that

will become:

Pattern: Testing this and that

if x is indeed greater than 5, or else it will be:

Pattern: Testing that

otherwise.

{@If(true) else }

{@If}: Conditional Directive

Description: A directive used to conditionally insert text or other directives into a pattern or replacement based on the result of a logical expression.

Note: This feature is currently in the design phase and is not yet implemented in the production engine.

Remarks

The {@If} directive allows for branching logic within the uCalc Transformer. It enables the engine to decide which text to output based on variables defined in the evaluator space or captured by pattern matchers.

Proposed Syntax

The recommended syntax follows a functional ternary structure:

• {@If: condition, then_part, else_part}

If the condition evaluates to non-zero (True), the then_part is inserted. If it evaluates to zero (False), the else_part is used.

Timing: Static (@) vs. Dynamic (@@)

• {@If: ...} (Static): The condition is checked once when the rule is created. This is useful for environment-based configuration (e.g., {@If: IsDebug, "[DEBUG] ", ""}).
• {@@If: ...} (Dynamic): The condition is checked for every match. This allows the output to change based on captured data (e.g., singular vs. plural formatting).

Variable Handling

Variables used in the condition (like those set by {@Define}) are accessed by name without curly braces. However, the then_part and else_part can contain standard placeholders or even other nested directives.

Examples (Proposed)

1. Succinct (Static Configuration)

Including a header based on a "TrialMode" variable set in the evaluator.

New(uCalc::Transformer, t)// Define statet.FromTo("{@Beginning}", "{@Define: Variable: TrialMode = 1}")// Static If check at rule creationt.FromTo("HEADER", "{@If: TrialMode, 'TRIAL VERSION', 'LICENSED VERSION'}")wl(t.Transform("HEADER"))

[Expected Output]TRIAL VERSION

2. Practical (Dynamic Pluralization)

Using captured counts to determine the correct suffix for a word.

New(uCalc::Transformer, t)// Capture 'n' and check if it's greater than 1t.FromTo("{@Number:n} items", "{n} {@@If: n > 1, 'items', 'item'}")wl(t.Transform("1 items; 5 items"))

[Expected Output]1 item; 5 items

3. Internal Test (Nested Logic)

Verifying that {@If} can be nested to handle more than two states.

New(uCalc::Transformer, t)t.FromTo("status {@Number:s}", "Status: {@@If: s==1, 'Active', {@@If: s==2, 'Pending', 'Inactive'}}")wl(t.Transform("status 2"))

[Expected Output]Status: Pending

Strategy & Critique

• Syntax Consistency: By using the comma-delimited (condition, then, else) format, {@If} feels like a natural extension of {@Eval}.
• Evaluation Context: The then and else parts should be treated as "templates" that are only parsed/transformed if their respective branch is chosen. This prevents unnecessary overhead or side effects from the unused branch.
• Critique: One challenge with comma-delimited syntax is handling commas within the then or else strings. We may need to support escaping (e.g., \,) or allow quoted strings for the branches.
• See Also: Refer to Topic 815 ({@Define}) for setting up variables used in conditions.