Should `TheoryModel`s use their underlying `ModelKind`s constructions more for getting the “equation” part of their descriptions?

[balacij]

Right now, theory models are constructed with ModelKinds whilst obeying a Theory typeclass and using that typeclass over the ModelKinds data, but I think @JacquesCarette previously mentioned that it (the Theory typeclass) was underdeveloped and underused. They currently diverge in functionality and usage compared to IMs and GDs, but with #2599, we're intended to unify them. Shall we just go ahead and make TMs follow the same style as IMs and GDs? I think this would also make the unification later on simpler.

@samm82 also has a bit of a continuity issue in his ChemCode program where he wants to use a custom ModelKind variant he created, but TheoryModels in their current shape must use expressions for their "equation" description box. Hence, he isn't able to expose his special theory to the SRS without some extra temporary measures.

TM (with ModelKind underused):

IM (with ModelKind appropriately used):

[smiths]

I like this idea. We held off with having input and output fields for TMs because of their more abstract nature. For instance, if we have the TM for Newton's Second law:

F = ma

We don't have to say which of F, m and a are known and which is unknown.

I think unifying theories (between TMs, GDs, IMs) is a more valuable goal than abstract theories. We should be able to create new theories that keep the same relation, but have different inputs and outputs, depending on the problem context.

[balacij]

Thank you @smiths :smile: I completely agree. On that note, are we clear to proceed?

Since we intend to unify the theories anyways, any feature that TMs should have, IMs and GDs should have as well, so I suppose the next step is to take a look at how this reduction of TMs would affect the generated SRS and the knowledge contained in the theories.

[smiths]

I'm fine with proceeding, but before we do too much work, we should check with @JacquesCarette. Investigating the impact on the generated SRS does seem like a good place to start.

[JacquesCarette]

What we need is to keep expanding ModelKind to have more features - such have having some theories that have inputs (and/or outputs).

Any changes to this infrastructure that does not change the output in any way is likely just fine. In a separate step, we can then also make changes to the output SRS so that things are more uniform.