overloading + to combine rules and rulesets

[gottacatchenall]

No description provided.

[rafaqz]

This looks good to me. Maybe apply https://github.com/invenia/BlueStyle which means spaces after commas, and no spaces in {T<:Ruleset} (I should also make this requirement clear in a PR template)

We could also copy the settings field from the left hand Ruleset, if you feel like doing that too.

Eventually we could define + for Ruleset + SimSettings so that its easy to add settings. But SimSettings hasn't been user-facing up to now and isn't exported. We might want to think about a better name for it, maybe just Settings?

Something like this could be nice:

ruleset = rule1 + rule2 + Settings(boundary=Wrap())

Edit: actually Settings could be different to SimSettings, with default values of nothing so you can just add a single setting and leave the rest unchanged. Or it just holds a NamedTuple.

[gottacatchenall]

Eventually we could define + for Ruleset + SimSettings so that its easy to add settings

This would be good and not too hard

---

We could also copy the settings field from the left hand Ruleset, if you feel like doing that too.

perhaps a getter for Ruleset settings (although only StaticRulesets hold settings at the moment)

settings(rs::T) where {T <: StaticRuleset} = rs.settings

and

Base.:+(a::T, b::V) where {T<:Ruleset,V<:Rule} = Ruleset(rules(a)...,b, settings(a))
Base.:+(a::T, b::V) where {T<:Rule,V<:Ruleset} = Ruleset(a,rules(b)...,, settings(b))
Base.:+(a::T, b::V) where {T<:Ruleset,V<:Ruleset} = Ruleset(rules(a)...,rules(b)..., settings(a))

[rafaqz]

They both do have a settings field, and there is a getter settings(ruleset). So your code example should already work.

We can actually add settings to a ruleset before the simulation, although there was a bug recently where they weren't being used.

For some background on settings and rulesets, there is a little bit of juggling to do with them that complicates things. Settings can be changed with sim! keywords or set at Ruleset definition to allow some flexibility. We have to keep the original Ruleset around as it can be the container for interactive parameter updates, for which it needs to be mutable. But that means we cant pass a Ruleset to a GPU kernel, as its mutable, and we also dont want the compile time of passing in all the rules. So the immutable SimSettings object is what ends up in a GPU kernel, as a field of RuleData.

(I think StaticRuleset is mostly redundant now we have SimSettings).

[rafaqz]

Probably * is more Julian for this, following String concatenation. Rules are also not commutative, like * for matrices.