Skip to content

Commit

Permalink
Use terminology 'evaluated parameter' when describing Evaluate
Browse files Browse the repository at this point in the history
  • Loading branch information
henrikt-ma committed Dec 12, 2020
1 parent a79c61b commit 23e1aec
Showing 1 changed file with 1 addition and 1 deletion.
2 changes: 1 addition & 1 deletion chapters/annotations.tex
Original file line number Diff line number Diff line change
Expand Up @@ -340,7 +340,7 @@ \section{Annotations for Code Generation}\label{annotations-for-code-generation}
In the case of multiple conflicting annotations it is handled similarly to modifiers (e.g., an \lstinline!Evaluate! annotation on the component declaration takes precedence).
The annotation \lstinline!Evaluate! is only allowed for parameters and constants.

Setting \lstinline!Evaluate = true! for a structural parameter, means that its value must be determined during translation, similar to a constant.
Setting \lstinline!Evaluate = true! for a structural parameter, means that it must be an evaluated parameter (i.e., its value must be determined during translation, similar to a constant).
For a normal parameter, it has no impact, and it is recommended to issue a warning (except when the parameter is normal due to dependency on a parameter with \lstinline!Evaluate = false!, as this could be a sign of intentional overriding of \lstinline!Evaluate = true!, see example below).
For both structural parameters and constants, the model developer further proposes to utilize the value for symbolic processing.
A constant can never be changed after translation, and it is normal for its value to be used for symbolic processing even without \lstinline!Evaluate = true!.
Expand Down

0 comments on commit 23e1aec

Please sign in to comment.