Houtan Bastani houtan.bastani@ens.fr writes:
It seems as though it would be good to discuss the evaluation rules for the Dynare 5 language on the list before going too far with the prototype. To animate this discussion, a simple series of commands in the new language would be useful:
a <- 1; b <- a + 1; a <- 2;
model { endogenous c; ...
equations { b = c*...; ... } }
Basically, we need to determine how to evaluate b in this situation:
- In the statement, b <- a + 1;, should b be evaluated to hold the value 2 or should it hold the symbolic value "a + 1"?
I’d say 2.
1a) If the answer is 2, should we allow for symbolic storage as well? I.e., the user could write something of the form: b <- sym(a) + 1; if they wanted to store the symbolic value "a + 1"?
Yes, something like that (maybe with a nicer syntax, possibly a single character quoting operator).
- In model-related blocks (model, calibration, initval, etc), should b in this case evaluate to 2, "a+1" or 3?
2a) If 2, this means that 1a from above holds 2b) If "a+1" this means that 1b from above holds 2c) If 3, this means that 1b from above holds but that, in model-type blocks, programming variables are evaluated by default (ie, b has the value "a+1" until it is used, at which point the last available value of a is looked up, in this case 2, and b is evaluated giving 3) NB: as above, we need to decide what the default behavior will be, whether or not we will enable all behaviors listed or others I missed, and, if enabling all behaviors, what delimiters we will use to do so (e.g. $, ', eval(), etc)
None of the above: it should remain as "b". And we should add an operator to force evaluation of b, which would in that case be replaced by its value, which is 2 according to the previous rule.
- Finally, we must decide whether to support model variable names
that overlap with programming variable names. For example, in this case, would it be ok to have endogenous a; or endogenous b;? Maybe it will lead to bugs in people's code to have this option. At the same time, since we're asking users to keep track of different types of variables in their mod files (i.e. programming variables versus model variables) as well as the scope of those variables (for loops for example) it seems quite natural to support this feature.
I think there is some confusion here. You are mixing the symbol (which is a string of characters) with its assigned value (in some evaluation environment). A symbol by itself is neither a programming variable nor a model variable. This is something that will change from Dynare 4 where currently a symbol is always of a given type; I think we should drop that rule.
Then you have evaluation environments that maps symbols to their values: these environments are only meaningful in a programming context; they are not relevant within a model context (except during the declaration of the model, where you could use programming features, possibly forcing evaluation with the associated operator).