Make 'constant expression' more restricted compared to full Modelica #2473
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…of variability Excluding impure function calls from parameter expressions is a similar simplification as requiring functions in constant expressions to be pure constant. To me, the two changes belong together and are therefore made part of the same PR.
…expressions According to poll in today's web meeting.
HansOlsson
reviewed
Feb 26, 2020
|
|
||
| ### Reason for change | ||
| By excluding `external` functions, translation time evaluation of constant expressions is greatly simplified. By excluding `impure` functions and `pure(…)` expressions, it is ensured that it doesn't matter whether evaluation happens at translation time or at simulation (initialization) time. | ||
|
|
||
| Forbidding translation time evaluation of function calls in non-constant expressions generalizes the current Modelica rule for `impure` functions and makes it clear that this is not allowed regardless whether this is seen as an optimization or not. (The current Modelica specification only has a non-normative paragraph saying that performing optimizations is not allowd.) | ||
|
|
||
| The change regarding parameter expressions could be extended to discrete-time expressions as well without loss of expressiveness due to the existing restrictions on where an impure function may be called. This could also be expressed more generally by saying that a function call expression where the callee is impure is a non-discrete-time expression. However, it was decided to not include this in the formal description of differences between Modelica and Flat Modelica in order to avoid describing changes that only clarify things without actually making a difference to semantics. |
There was a problem hiding this comment.
I don't see how this is true for discrete-time expressions. You are allowed to call impure functions in when-clauses, and the result is a discrete-time expressions. That is sort of the intended way to communicate with external systems.
There was a problem hiding this comment.
It is true because the rule of capping the variability inside when-clauses to discrete-time still applies.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The goal of this change is to ensure that a constant expression can be evaluated at translation time.
The proposed way of achieving this is to identify a special kind of pure functions that are the ones that can be called in a constant expression.