Type incompatible if-expressions whose condition depends on function input

[perost]

Modelica.Mechanics.MultiBody.Frames.TransformationMatrices.smallRotation is currently declared like this:

function smallRotation 
  extends Modelica.Icons.Function;
  input TransformationMatrices.Orientation T;
  input Boolean withResidues = false;
  output Modelica.SIunits.Angle[if withResidues then 6 else 3] phi;
algorithm
  phi := if withResidues then {T[2, 3], -T[1, 3], T[1, 2], T[1, 1] - 1, T[2, 2] - 1, T[1, 1] * T[2, 2] - T[2, 1] * T[1, 2] - 1} else {T[2, 3], -T[1, 3], T[1, 2]};
  annotation(Inline = true); 
end smallRotation;

The specification currently just says that the two branches of an if-expression must be type compatible, but I believe it's generally agreed that this does not need to be the case if the condition can be evaluated (see #2165).

But in this case we have type incompatible branches and a condition that's a function input. Is this supposed to be allowed? And if so, how is it supposed to be handled?

[HansOlsson]

...
The specification currently just says that the two branches of an if-expression must be type compatible, but I believe it's generally agreed that this does not need to be the case if the condition can be evaluated (see #2165).

But in this case we have type incompatible branches and a condition that's a function input. Is this supposed to be allowed? And if so, how is it supposed to be handled?

To me it would be natural to allow it, since evaluating the functions require that function inputs are known literals - and thus we can evaluate the if-condition.

[perost]

To me it would be natural to allow it, since evaluating the functions require that function inputs are known literals - and thus we can evaluate the if-condition.

Yes, but I assume there's a need to determine the type of the if-expression before evaluating the function, since the evaluation might not happen until during simulation. We could of course just say that the type of the if-expression is e.g. Real[if withResidues then 6 else 3], since the specification allows array dimensions to be computed at run-time, but the rules for if-expressions needs to be changed in that case.

[HansOlsson]

To me it would be natural to allow it, since evaluating the functions require that function inputs are known literals - and thus we can evaluate the if-condition.

Yes, but I assume there's a need to determine the type of the if-expression before evaluating the function, since the evaluation might not happen until during simulation. We could of course just say that the type of the if-expression is e.g. Real[if withResidues then 6 else 3], since the specification allows array dimensions to be computed at run-time, but the rules for if-expressions needs to be changed in that case.

That is my preference, i.e., update the rules for if-expressions in functions (and possibly other cases as well?) to allow run-time evaluation/check of sizes. Since we can dynamically change the size of an output-variable in a function it makes sense that if-expressions can match that.

[HansOlsson]

Possibilities:

• Allow in general in functions.
• Only allow if condition is input
• Allow in general in algorithms
• Could rewrite as if-statement, but similar issue with assignment in the wrong branch
  Postpone.

[HansOlsson]

An example:

function foo
  input Integer n(min=1);
  output Real x[n];
algorithm
  x:=if n==1 then {1.5} else linspace(1,2,n);
end foo;

[HansOlsson]

Conclusion: seems that we can at least allow in functions, but can we allow it in a more general sense?

[HansOlsson]

Conclusion: seems that we can at least allow in functions, but can we allow it in a more general sense?

Has anyone investigated the latter part in more detail?