Fix @mtkmodel to work without using ModelingToolkit

[cstjean]

Fix #3640

Incidentally, include("test/model_parsing.jl") at the REPL fails with

ERROR: LoadError: IOError: stat("//www.w3.org/2000\\svg\" width=\"80\" height=\"30\">\n<path d=\"M10 15\nl15 0\nl2.5 -5\nl5 10\nl5 -10\nl5 10\nl5 -10\nl5 10\nl2.5 -5\nl15 0\" stroke=\"black\" stroke-width=\"1\" stroke-linejoin=\"bevel\" fill=\"none\"><\\path>\n<\\svg>\n"): unknown error (UNKNOWN)

on Windows. Is there an easy fix for that?

[AayushSabharwal]

Is prepending $MTK. to everything really the solution? What if we did this instead:

Suggested change

	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.

[cstjean]

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.

?

[AayushSabharwal]

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 @variables is 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?

[cstjean]

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.