Enable `AssignmentAffect` for simple events

[TorkelE]

Previously, you had events on the form p ~ p + 1, where the left-hand side was the symbolic variable you wanted to update, and the right-hand side the expression you wanted to assign it to. With the new events, we can make much more general events, however, it complicated the simple eventsl ike this as you now have to specify discrete_parameters, which requires importing ModelingToolkitBase.SymbolicDiscreteCallback and similar.

Per previous discussion, it would be useful to have a special constructor that assmues the old simplified affect syntax. I.e. you could do

... => AssignmentAffect(p ~ p + 1)

which is automatically inferred to be

SymbolicDiscreteCallback(... => p ~ Pre(p) + 1; discrete_parameters = p)

The reason this is useful is that, within the Catalyst DSL, we do not have the option of using arguments as discrete_parameters. My soolution would be:

1. The DSL only supports the simple assignment events (this is >95% of the events we would expect anyway).
2. People who want to use more complicated events either have to interpoalte them into the DSL, or use programmatic modelling).

Currently, I have a normal implementation of this, however, if MTK had a AssignmentAffect or similar, I could simply dispatch to that, and MTK could do the related work, which probably is a more sensible solution. It could likely be useful to others as well who are in similar situations.

[AayushSabharwal]

Should AssignmentAffect support multiple assignments? Are they then independent assignments or imperative?

[TorkelE]

As in

AssignmentAffect([p ~ p + 1, X ~ X + 1])

?

I think this would be useful, but maybet here are considerations where this becomes compliacted? I think you are hinting at that?

[AayushSabharwal]

Consider

AssignmentAffect([p ~ p + 1, q ~ p + 2])

Is this equivalent to

[p ~ Pre(p) + 1, q ~ Pre(p) + 2]

or

[p ~ Pre(p) + 1, q ~ p + 2]

?

Note that the latter is MTK's old semantics (prior to Pre). The order of assignments then matters. If the order of equations passed to AssignmentAffect in the above example is reversed, the equivalent semantics are

[q ~ Pre(p) + 2, p ~ Pre(p) + 1]

Since we assign to q first and then to p.

[AayushSabharwal]

I'd also prefer using something like => over ~, since this is imperative and not declarative.

[ChrisRackauckas]

Yes these are not equalities so it shouldn't pun ~

[TorkelE]

I think your first suggestion, is better, i.e. make the set up so that order does not matter.

You mean doing something like

AssignmentAffect([p => p + 1])

? That could make sense. Might even be able to make it work without the AssignmentAffect constructor, i.e. if you pass something on that form it is automatially assumed to be an assignemtn affect.

These notations have basically identical expression structure to p ~ p + 1:

p => p + 1
p <= p + 1
p <- p + 1

(just storing =>/<= as the first argument, rather than ~), so could be handled basically identically.