Showing "f(x,y,z)"-like forms on the left-hand side of QDefinition equations

[balacij]

Related to #2371.
Related code. deleted it since it's already here below.

While trying to convert the only InstanceModel of the DblPendulum example, I came across an issue with getting the QDefinition to render the left-hand side of the equation as it does currently, with the left-hand side showing "theta_p as a function of time".

Presently, a few of the examples that don't generate code have RelationConcepts with Relations (Exprs) that are of the form:

angularDisplacementRC :: RelationConcept
angularDisplacementRC = makeRC "angularDisplacementRC" (nounPhraseSP "calculation of angular displacement")
  EmptyS $ apply1 pendDisplacementAngle time $= sy initialPendAngle * cos ( sy angularFrequency * sy time)

(This is the RelationConcept used in the sole InstanceModel in DblPendulum)

Specifically, the left-hand side of the equality is apply1 pendDisplacementAngle time, theta_p as a function of time, currently displayed with (t) in the equation of the InstanceModel information box.

Unfortunately, this is not currently easily convertible into a QDefinition using relToQD without changing the apply1 pendDisplacementAngle time into just a sy pendDisplacementAngle (e.g., C "pendDisplacementAngle") because relToQD (and it's helper, convRel) only act on things of the form EqBinaryOp Eq (C x) r directly while the apply1 pendDisplacementAngle time is a FCall (not a C).

It's also not quite straightforward to convert this into a QDefinition directly either (at least from what I've tried at the moment, but I might be wrong!). The "left hand side" (apply1 pendDisplacementAngle time) that we want to be the target of the definition is currently of type Expr but we would need it to be of type Symbol (I believe) for when displaying. We have tons of nice smart constructors for writing Symbols.

Giving it a go (just using p with a subscript theta [intentionally backwards/incorrect], without the "t input" yet)...

angularDisplacementQD :: QDefinition
angularDisplacementQD = fromEqn' "pendDisplacementAngle"
  (nounPhraseSP "calculation of angular displacement")
  EmptyS (sub lP lTheta) Real (sy initialPendAngle * cos (sy angularFrequency * sy time))

And the left-hand side shows as theta_p, showing that this symbol override is not actually respected. It is just getting the symbol of the pendDisplacementAngle UID instead, which is:

pendDisplacementAngle :: UnitalChunk
pendDisplacementAngle = makeUCWDS "pendDisplacementAngle" (cn "displacement angle of pendulum")
        (phrase angle `the_ofThe` phrase pendulum)
        (sub lTheta lP) degree

At first, I thought this had to do with the HasSymbol instance for InstanceModels, so I changed

instance HasSymbol InstanceModel where symbol = symbol . view output

into:

instance HasSymbol InstanceModel where
  symbol (IM (EquationalModel q) _ _ _ _ _ _ _) = symbol q
  symbol im_                                    = symbol (view output im_)

where I set the symbol of an equational instance model to be that of the equational models' QDefinition. Unfortunately, it didn't change anything. However, I think this change still makes sense to do regardless because the equational models are definitional. ( please let me know your thoughts about this )

Moving on, I checked the same instance declaration for QDefinition, for which I think makes sense. It's the symbol of it's internal QuantityDict. However, if we wanted to make this change of having left-hand side of equations shown as functions of input variables, then I believe this might be the area that we primarily edit (using the stage perhaps explicitly here to show when to have/not have the "function inputs tuple" shown), though I'm not 100% sure as I haven't tested it yet. However, I believe that altering this would affect many of the currently generated examples.

I'm not yet quite sure how to proceed with fixing this, but I have a feeling that this isn't something that should be fixed in isolation. I think that this would have a greater impact on how we generally show equations in InstanceModels. With the exception of NoPCM's IM: heatEInWtr, none of the current examples that generate code have this same area where a QDefinition has a left-hand side of an equation shown with the "function of X,Y,Z" syntax. With regards to the NoPCM heatEInWtr example, the _definitions of it's Body's SystemInformation is currently empty (is this normal? if we add it to _definitions, then it would cause a problem with the relToQD issue mentioned above) which is why this issue does not occur with it. It appears to be rendered differently, which I haven't yet fully figured out.

Do we want to have f(a,b, ..., z) or just f shown on the left-hand side of EquationalModel equations? If we want the former, do we also want these arguments to appear inside of the function calls used in expressions? If we want the latter, should I just change stable with this particular example, or do we want just this example in particular shown as a function of some inputs?

Should all InstanceModels' equations always be added to the _definitions lists in the SystemInformations?

Is there any thoughts on this? Any help would be greatly appreciated 😄

[JacquesCarette]

So this is mixed up with types. The pendulum displacement angle is not really a number (with degree as units), but a function of time that returns a number.

So the angular displacement should either not be a quantity, or we need to clearly indicate which quantities are constants and which are variable. From an FP point of view, it makes sense to treat functions as first-class, but I don't know if Drasil is quite ready yet for that.

I don't like the change to instance HasSymbol InstanceModel. The lack of uniformity strikes me as odd.

My feeling is that quantities should be scalar (i.e. constants), and that we need FunctionDefinition as a new data-structure. Then we'll need a new kind of model too, I think, that understands models defined by functions.

[balacij]

I started working on this on the functionDefinitions branch because I think it's another issue that's needed to be completed before #2628, but I've yet to capture the function spaces needed in #2554 properly.

Currently, I have function spaces using uncurried inputs AxBxC -> D instead of curried, also disallowing function spaces as parameters. I'll try to change it to those required for #2554 and it's origin #2395, but I'm not if this would cause any issues in terms of ability to generate code for the OO languages without having them error out on generation.

[JacquesCarette]

For the sake of OO languages, I agree that currently going for just first-order functions and uncurried is the way to go. We can re-examine this once that much is working.

[balacij]

Sounds good. I'll create a PR draft then!