Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

List item scope in "Restrictions on Equations within When-Equations" #3291

Closed
bilderbuchi opened this issue Nov 23, 2022 · 1 comment · Fixed by #3292
Closed

List item scope in "Restrictions on Equations within When-Equations" #3291

bilderbuchi opened this issue Nov 23, 2022 · 1 comment · Fixed by #3292

Comments

@bilderbuchi
Copy link

In the current master spec, we have (bold emphasis mine)

8.3.5.3 Restrictions on Equations within When-Equations

The equations within the when-equation must have one of the following forms:

  • v = expr;
  • (out1, out2, out3, …) = function_call_name(in1, in2, …);
  • Operators assert, terminate, reinit.
  • For- and if-equations if the equations within the for- and if-equations satisfy these requirements.
  • The different branches of when/elsewhen must have the same set of component references on the left-hand side.
  • The branches of an if-then-else clause inside when-equations must have the same set of component references on the left-hand side, unless the if-then-else have exclusively parameter expressions as switching conditions.

Any left hand side reference, (v, out1, …), in a when-clause must be a component reference, and any indices must be parameter expressions.

I suspect that the last two bullet points should not be items of the list, but should be following the list, so form additional requirements on top of the respective chosen bullet item.

According to the current form quoted above, and taking note of the bolded part, the following example would be legal:

 equation
  when x > 2 then
    y = 5; // compliant with bullet 1
  elsewhen x > 3 then
    z = 5;  // compliant with bullet 1
  end when;
HansOlsson added a commit to HansOlsson/ModelicaSpecification that referenced this issue Nov 23, 2022
…are different forms.

The problem was introduced in Modelica 2.0 when the new restrictions were added.
Closes modelica#3291
@HansOlsson
Copy link
Collaborator

Agreed, and I also think that the trailing restriction could be added to that list.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants