Hello,
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:
1) In the statement, b <- a + 1;, should b be evaluated to hold the value 2 or should it hold the symbolic value "a + 1"? 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"? 1b) If the answer is "a + 1", should we allow for some type of forced evaluation notion to make b take the value 2? I.e., something of the form b <- eval(a) + 1;? NB: We could replace sym and eval by whatever we wanted (some languages use a preceding $ sign or quote). The idea here is mainly to decide the functionality we want to support (i.e. both 1a and 1b or just one or the other) as well as the default functionality (either 1a or 1b), but if people have strong preferences for/against a certain delimiter, they should be stated.
2) 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)
3) 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.
Best, Houtan