Re-design `FCall` to allow typing

[balacij]

Posting this issue as a snippet of discussions from Dr. Carette and I.

is there an issue associated with FunctionCall? This seems to need real design too.

From @JacquesCarette

Yes, the list of Exprs as a parameter in FCall :: UID -> [Expr] -> [(UID, Expr)] -> Expr will be problematic for it. We could quickly hack a fix by using some container that discards Exprs soon-to-be type variable however, approximately:

data IgnoreTypeVar t = forall a. IgnoreTypeVar (t a)

and then impose type restrictions from the smart constructors (for which we would need to create multiple versions; enumerating over a reasonable number of parameters for functions -- I would assume smart constructors for functions with 1-5 arguments would be a reasonable start, but it will quickly become ugly when we have more than 10 arguments).

However, since we only define functions through QDefinitions, we might also want to re-consider how we bring variables into the expressions of QDefinitions. A recurring idea to me is to try to express them with Haskell-level anonymous functions with Haskell-level parameters for each QuantityDict/Expr-level variable, but I'll need to think about this more. I'll try to get back to you soon with a better answer.

From @balacij

inxi is the symptom for the fact that we don’t have a representation for indexing. But ‘indexing’ is really a special form of function application that we denote differently to connote the fact that the domain is bounded and discrete. Internally, we could denote these by decorated functions (i.e. our data-structure for functions could have some meta-data attached to it)

From @JacquesCarette regarding the remaining ModelKinds in #2371's inxi-models

Re: FCall. We should probably consider implementing 2 things: 1. small-sized tuples (as you mention), and 2. use currying. We shouldn’t force things in one shape or another. That would be better than the IgnoreTypeVar.

Re: only defining functions through QDefinition. That’s potentially an artifact of our current examples and lack of support for functions. I want to keep some separation between Expr and ‘chunks’. We need to be able to represent the core of functions in our expression language. QDefinition should use that. QDefinition is really about the meta data around “defining a known quantity”. Expr is the language to use for the details.

From @JacquesCarette