Clarify simple function call.

[HansOlsson]

I noticed that the issue had milestone 3.7 so I thought it best to have at least a proposal for a solution; even if we decide to postpone it.

Closes #3632

Future possibilities:

• Could group reinit, assert, terminate in a sub-section of their own (and thus move them down one level), and put this explanation at that place (but still referenced from simple equation).
• Modify the grammar as it currently contains:

some-equation :
( equation-or-procedure
  | if-equation
  | for-equation
  | connect-equation
  | when-equation
)
description

equation-or-procedure :
simple-equation
| function-call

connect-equation :
connect "(" component-reference "," component-reference ")"

To me it would be logical to group function-call and connect-equation after each other inside equation-or-procedure. However, we cannot view connect-equation as a kind of function-call as connect is a keyword and break connect-equation is used for selective model extension.

[henrikt-ma]

To me it would be logical to group function-call and connect-equation after each other inside equation-or-procedure. However, we cannot view connect-equation as a kind of function-call as connect is a keyword and break connect-equation is used for selective model extension.

The only use of equation-or-procedure and statement-or-procedure that I see is that they are mentioned non-normatively when talking about how to write a recursive descent parser. If we omitted that non-normative section, we wouldn't have to draw an artificial line between what goes directly into some-equation (statement) and what goes into equation-or-procedure (statement-or-procedure).

[henrikt-ma]

Is this new semantics, or is this already established in some other form somewhere else? (I am surprised that this would be allowed for a function with outputs; I would have expected that a simple equation/assignment with an empty parenthesis in the left-hand side was needed.)

[HansOlsson]

Suggested change

	It behaves similarly to a simple equation (calling the function or operator but ignoring any potential output), even if it uses a different production in the grammar.
	It behaves similarly to a simple equation (calling the function or operator), even if it uses a different production in the grammar.

I'll have to investigate more to see if it exists, but for now it seems simplest to just remove that part; to not draw attention to it. In general procedure calls have not been handled well.

Note: I assume you specifically mean the part about ignoring outputs; as the other semantics is already used in MSL, e.g., for Modelica.Utilities.Streams.print, Modelica.Utilities.Streams.error (and some assert-media function as far as I recall).

Ignoring outputs is implicitly assumed in https://specification.modelica.org/master/interface-or-type-relationships.html#function-compatibility-or-function-subtyping-for-functions - because otherwise a function adding a new output after the last one would need a sub-typing exception for functions with no outputs.

[HansOlsson]

Since it is delayed we can discuss and clarify it further, including stating that procedure call for functions with outputs is not recommended, but simplifies function sub-typing.

[HansOlsson]

Delay