Hi Sebastien Sébastien Villemot writes:
Hi Michel,
Le mardi 24 mars 2020 à 17:11 +0100, Michel Juillard a écrit :
Dear Friends, I have been using recently both the option language=julia that I startedusing some time ago in https://github.com/MichelJuillard/dynare.jl andthe JSON representation of the *.mod file. I feel that it is the moment to decide wether we adopt one or theother. My preference goes to the JSON interface for the followingreasons:1. It is a strain on resources to try to develop both2. The JSON interface has potential usages outside of the Dynare inJulia project.3. It is relatively straithforward to implement the JSON interace in thepreprocessor with a few intuitive standard fields for the JSONs.4. The Julia implementation can then be done entirely in Julia.5. On the contrary, developing the option language=julia requires todevelop in parallel the preprorcessor and the Julia implementation ofDynare commands.
Note that the JSON format is already used outside Julia (in particular by code for the ECB-MC model).
I don’t see the Julia and JSON backends as interchangeable, and I’m therefore not sure that we should drop either. But Stéphane and Houtan can probably better comment on that, since they designed both backends.
You are right. language=julia (with in addition the output option) creates dynamic.jl and static.jl. My remark concerns indeed the <mod filename>.jl file. I believe it will be easier to develop Dynare in Julia if one uses the JSON file instead of the above file.
If we go that way, I will make sure that the code in dynare.jl works,but I will stop developing that git project and start afresh in a newgit project. I have created https://gitlab.com/dynare-julia as a groupof projects. I want to develop separate packages for the low levelcode that isn't Dynare specific. These packages must go is separategit projects under the dynare-julia umbrella.
If those packages are unrelated to Dynare, I’m afraid putting “dynare” in the name of the group will only confuse users.
On the other hand, if they are somewhat related to Dynare, I think they should rather be hosted on git.dynare.org (possibly in a new group there).
I will move these files to a different location without reference to the dynare name
Best,