Fix @mtkmodel to work without using ModelingToolkit #3643
Conversation
See SciML#3640 Feels like `const MTK = ModelingToolkit` should be at the top-level for convenience.
| push!(exprs.args, :(systems = ModelingToolkit.AbstractSystem[])) | ||
| push!(exprs.args, :(equations = Union{Equation, Vector{Equation}}[])) | ||
| push!(exprs.args, :(defaults = Dict{Num, Union{Number, Symbol, Function}}())) | ||
| push!(exprs.args, :(systems = $MTK.AbstractSystem[])) |
There was a problem hiding this comment.
Is prepending $MTK. to everything really the solution? What if we did this instead:
| push!(exprs.args, :(systems = $MTK.AbstractSystem[])) | |
| push!(exprs.args, :(systems = $AbstractSystem[])) |
Also wouldn't this need to be done in more places? e.g. where @variables is called.
There was a problem hiding this comment.
See the discussion around https://discourse.julialang.org/t/adding-method-to-function-in-macro/128613/6 . If you're going to esc the expression, then you need either $MTK.AbstractSystem or $AbstractSystem, but there are places where the latter will fail. In particular, you can't $@some_macro obviously. I always use the former style for that reason, but I don't mind changing this PR to $AbstractSystem if that's your preference.
Also wouldn't this need to be done in more places?
Yes, absolutely. I didn't want to venture outside of my MTK comfort zone.
e.g. where @variables is called.
?
There was a problem hiding this comment.
See the discussion around https://discourse.julialang.org/t/adding-method-to-function-in-macro/128613/6 . If you're going to esc the expression, then you need either $MTK.AbstractSystem or $AbstractSystem, but there are places where the latter will fail
I see, thanks for clarifying. $MTK is fine, then.
e.g. where
@variablesis called.?
While parsing @variables inside @mtkmodel, we generate code that calls Symbolics.@variables and MTK.@parameters. I assume those need to be qualified as well?
There was a problem hiding this comment.
Yes, I always prefix functions, types and macros with $MyModule. when using esc. It's the flip side of skipping macro hygiene. It can also prevent unnecessary conflicts if ModelingToolkit and SomeOtherLibrary export the same symbol.
In this particular case it doesn't matter because the user will feel compelled to import ModelingToolkit: @variables anyway, but that's not reliable in general.
Fix #3640
Incidentally,
include("test/model_parsing.jl")at the REPL fails withon Windows. Is there an easy fix for that?