Decouple names from system construction

[ChrisRackauckas]

I want the names that a system assumes to be decoupled from the actual usage of the system itself. The reason is because the importance of this package is really to be an intermediate of model transformations that DSLs can plug into. We are already starting to build many different DSLs which utilize this intermediate, and one thing I've noticed is that we don't want to be constrained in subtype naming due to the systems that we want to target. For example, we want to have some biological model (like @AleMorales 's) and name things Reactants and stuff like that, but when we build the ODE we want to just say "these variables are the dependent variables, these are the independent variables, etc." and have it run to generate ODEs from there, as opposed to requiring DependentVariable, IndependentVariable, etc. (these won't go away, but will just be the defaults).

Most of the change was pretty simple. 2132199 did most. However, there are two problems to fix up:

1. We need variables to know their dependence themselves in order to simplify derivatives to zero ( require variable dependence #47 )
2. We need to have extract_derivatives handle aliasing. For example, right here is a hack that allows both :Variable and :DependentVariable to be used in the nonlinear system ( https://github.com/JuliaDiffEq/SciCompDSL.jl/blob/master/src/systems/nonlinear/nonlinear_system.jl#L8-L13 ), but we should make this more general and allow extract_elements to take in a vector of symbols and extract both subtypes into that form. extract_elements should also have a place of putting "all other names", i.e. not giving them special treatment. For example, in the DiffEqSystem we want :Variable to be used for just some intermediate calculations, but in reality it's just anything that's not an independent or dependent variable that should be treated like that.

If we have this, then I think that we can build DSLs with its own naming systems and all of that, but still pull from the same transformation, Jacobian building, and compilation system, which is the ultimate goal.

@YingboMa can you look at (1)? @AleMorales can you take a look at (2)?

[AleMorales]

I can certainly take a look. An option is to explicitly map the initial and final subtypes (e.g. DependentVariable => Variable for the nonlinear system hack) and have some default for the rest.

But I think there is a bigger issue than naming and is the fact that certain DSL will also require to create their own types that eventually lower into a Variable of a given subtype (potentially losing information in the process, which we may not want to). Making Expression an abstract type was a great step forward as I can create my own types that generate correct Operations, when applying the registered functions (and lower them to Variable at the end). But that makes me wonder whether DependentVariable et al. should also be abstract types (or some orthogonal trait system) rather than types.

[ChrisRackauckas]

But that makes me wonder whether DependentVariable et al. should also be abstract types (or some orthogonal trait system) rather than types.

The issue there is that it will never be inferrable, so we'd want to avoid types as otherwise things could slow to a crawl because every piece of code becomes dynamic. As we have it, most things are non-dynamic except for Expression vectors. This is a lot like Julia's AST which uses symbols for things like functions in order to avoid overtyping. But,

But I think there is a bigger issue than naming and is the fact that certain DSL will also require to create their own types that eventually lower into a Variable of a given subtype (potentially losing information in the process, which we may not want to).

That shouldn't lose any information if we just allow information by composition. If we just allow a boxed composition pointer, then most of the generic routines can safely ignore that without an issue.

An option is to explicitly map the initial and final subtypes (e.g. DependentVariable => Variable for the nonlinear system hack) and have some default for the rest.

I don't think we need to explicitly map since making the names flexible will have other advantages anyways.

[ChrisRackauckas]

Generic composition is now allowed via the context field.

[ChrisRackauckas]

(1) is complete.