Assuming
param p = 53;
Will the expression
(p - 11)
be guaranteed evaluated at compile time or do I need to declare that expression as a param
Thx.
Assuming
param p = 53;
Will the expression
(p - 11)
be guaranteed evaluated at compile time or do I need to declare that expression as a param
Thx.
Hi Damian —
The subtraction of the two params will definitely happen at compile-time. The only reason to store it into a declared param
would be if you wanted to "prove" to yourself that this was happening at compile-time for a given expression since, if it wasn't, the newly declared param wouldn't be able to be initialized with it.
Bottom line: when a given param-generating operation or call is defined for params and called with params, it will be computed at compile-time independently of how the result is used.
-Brad
Expanding this just a bit, just in case it wasn't totally clear, not all functions in the standard library will return params. E.g. proc f(param arg: int) param { return arg; }
is defined for params (uses the param intent on arg
) and generates a param (uses the param return intent). In contrast proc g(arg: int) { return arg; }
is neither defined for params nor does it generate / return a param.
So, if you have some params/literals and you call a standard library function, it depends on what you call whether or not the result will be param. It'll be param for the usual operators +
-
*
/
(which have such param
overloads in the standard library) and many functions (e.g. abs
) but not, for example, for sin
(which does not). If you are uncertain about a particular function, you can check by looking at the overloads of these or by storing the result of such an expression into a param
.
So, if you have a bunch of params/literals and you call something, the compiler will decide based on what is called whether or not the result is param. But whether it stays param, or gets put into a runtime variable from there, depends on what you do with it. Here is an example:
param p = 53;
param q = p - 11; // p-11 is param and stored in the param q
var x = p - 11; // x is not param; it was only initialized to something that is param
g(p - 11); // p - 11 is computed as param & this is passed to `g`
// 'g' doesn't accept a param, so it will be passed a
// runtime value initiaized by the param p-11.
proc g(arg: int) { return arg; } // formal argument 'arg' is not param
Usually, the reason one cares about something being param
is that one wants to pass it in to something needs to happen at compile time (creating a type, for example; or calling a function that uses a param
formal argument to specialize). The compiler will require a param
in these cases, so you will see a compilation error if something caused it to no longer be param
& it is then passed to a param
formal argument).
Thanks heaps Brad and Michael for the explanation