Why does the preprocessor do more than just compile the mod-file?

Macro-language
1

This post is more of a suggestion than a specific issue.

The preprocessor is a powerful tool for scaling models and embedding them within a dynamic interface. As I understand it, its primary role is to compile the mod-file, which is then converted into an m-file.

However, the preprocessor does more than just compilation—it also performs sense-checking on the mod-file, extending beyond simple syntax validation. For instance, if a user attempts to run a deterministic simulation while specifying a non-existent shock, the preprocessing will fail.

My question is: If an error is Dynare-specific rather than a syntax or preprocessing-related issue, why doesn’t Dynare allow the preprocessor to complete its task and instead let Dynare produce the error when running the processed mod-file?

This would be particularly useful when users want to implement manual consistency checks and provide customized error messages. Currently, these manual checks are never executed because preprocessing fails before they can be reached.

2

The goal of the preprocessor is to translate the .mod file into a representation that can be used in e.g. Matlab. When doing so, checks are performed that the .mod file makes sense.

We have the nostrict command line option to have the preprocessor not error out for various issues that may appear during model building. An example is having shocks specified that are not used. Have you tried it? You can even put it at the beginning of a mod-file via

// --+ options: nostrict +--

in the first line. You then don’t need to specify it at the command line.

3

Thank you for the response! I’m using the nostrict option when invoking Dynare and it is very useful.

One particular example (there may be others) when the pre-processor breaks even with the nostrict option in place is when the user adds an exogenous variable in the shock block that is (a) not declared and (b) not added to the model block.

For most applications it totally makes sense that the pre-processor breaks in that case but it does come at the cost that the model cannot inform the user with a customized error message.

If the preprocesser was running through, however, one could add something like this to the mod file:

if ~ismember(@{some_shock_name},M_.exo_names) 
    fprinf('The shock @{some_shock_name} you're trying to simulate is not correctly implemented.')
    return
end

I just wanted to flag that there may be use cases where a more forgiving preprocessor would give the modeler more flexibility in dealing with errors.