Extend conditional parameter support to if-expressions and if-equations

[AntoineGautier]

Context

This issue follows up on #3489 and #3391, which introduced the change now in MLS 3.7-dev that allows the use of conditional components outside of connect statements – and in particular, conditional parameters in modifiers of other conditional components:

Such a component can only be modified, used in connections, and/or used in a modifier of another conditional component with a false condition.

This change is key to support class parameterization in practice – where model developers can easily adapt the set of parameters to that required by the conditionally enabled components.

Until now, we've been dealing with "conditionally required" parameters using the syntax "start attribute+enable annotation", based on the following semantics:

If enable = false, the input field may be disabled and no input can be given.

Although simple at first glance, in practice, this pattern turns out to be incredibly difficult to implement for non-scalar parameters (records and arrays) and poses real challenges for cross-tool support.

Issue

The proposed change in MLS 3.7-dev moves in the right direction. However, the fact that conditional parameters cannot be used in if-equations or if-expressions feels like the gap is only halfway bridged.
In practice, this means we must maintain two distinct idioms for parameters that don't even appear in the flat equation system – the new conditional form and the legacy start+enable pattern. Rather than simplifying our codebase, we anticipate increased complexity and inconsistency in model development.

Test Package

We have developed a test package to illustrate the cases that we think should be supported:
https://github.com/AntoineGautier/modelica-conditional-parameters/blob/master/TestConditionalParameter.mo

• At least: model O where a conditional parameter is used in an if-expression within a declaration equation:

  Real x = if use_p then p else 0;  // where p is conditional on use_p

• At best: model M where a conditional parameter is used in an if-equation:

  if use_p then
    x = p;
  else
    x = 2;
  end if;

We would be happy even with the additional requirement that the condition relied on parameter expressions evaluated at translation.

The package includes inline comments showing how these constructs are supported by various Modelica tools.
Two of the three tools we tested already support what we want. This suggests the change is achievable from a compiler development standpoint.

We regret not engaging earlier in the discussions on #3489 and #3391, and hope it is not too late to raise this point.

--
Pinging @mwetter for information.

[HansOlsson]

For the example: Real x if use_p;

[HansOlsson]

Seems to be three options:

• Special construct forcing evaluation, similar to if constexpr in C++.
• Evaluating the conditional forces evaluation of the parameter, and we should simplify everything based on it (so a parameter with "if use_p;" caused use_p to be evaluated and all conditions using use_p must be evaluated as much as possible - we need to clarify exactly what is evaluated in that case).
• Using a disabled conditional component forces the evaluation of the surrounding conditions (if it is deeply nested we need to specify whether to start from top or bottom).