How are unmodular feature flags related to existing `Choices`?

[balacij]

Recall Choices. In particular, I am interested in us looking at (2) and (3).

The goal of this ticket is to understand how we should add unmodular feature flags to Choices.

For starters, I want to add the following feature flags:

1. NoSimpleCalculationFunctions: this is essentially a weaker version of Make unmodular code generation a bit more unmodular #4233 where all code that would go into "simple calculation functions" would instead be inlined. Specifically, this would not inline "function definitions" (these would remain as functions) nor ODEs (these would again be left as extra functions that do the necessary prep work to make ODEs happen).
2. InlineOutputFunction: inline the write_output function in the main "controller" function.
3. InlineInputCalculations: inline all input-related calculations (constraint validation, derived inputs, and reading inputs) in the main "controller" function.

Note: the "controller" function is the function that we often place in the Calculations.py files that calls all other modules.

Now, some questions that would help us:

-1. What is "modularity"?

For the sake of providing a working definition, I'm going to work on the assumption that "modularity" is a spectrum involving splitting up code into "modules" exhibiting:

1. High cohesion: "modules" have well-defined purposes/clear scopes and all components of them are strictly relevant to said purpose/scope.
2. Low coupling: "modules" are highly independant, communicating with well-defined interfaces and not reliant on external shared knowledge.
3. Encapsulation: using "modules" that only expose what is absolutely necessary to interacting with it -- showing no internal complexity.

Now, with the existing Modularity data type, we are reducing "modularity" to a binary that isn't exactly true in the general case, but because this is in the context of generating code, we have the ability to make outputs "completely modular up to $X$ or completely unmodular up to $Y$."

0. What other feature flags would we be interested in?

For now, I think the above 3 are a good starting point, but I'm sure there are tons of other things we would want to turn on and off!

1. Is Modularity a feature only relevant to Program?

I don't think so? If a Modular Library generates all of the simple calculation functions, then I would assume that the Unmodular Library generates a single calculation function that, instead of inputting and outputting from stdin/stdout/files like its Program counterpart would, would just rely on an InputParameters class fed in to it (or just an enumeration of input parameters) and return an Outputs class (or again, an enumeration of output variables).

The other 2 feature flags are not really as relevant to Library.

2. Are these feature flags only relevant to Unmodular?

For example, I think that NoSimpleCalculationFunctions could also be relevant to Modular. However, the criteria for "simple" might be a bit different. For Unmodular, "simple" would mean any/all of our existing calculation functions, but for Modular, it could mean that the expressions are considered "complex" if their relevant expression ASTs are of a particular depth.

The other 2 feature flags are not really as relevant to Modular.

3. How is DataInfo related to modularity?

DataInfo contains the following settings:

    inputStructure: a decision on input the structure of variables
        Unbundled: each input variable was directly passed to the function as its own parameter.
        Bundled: all input variables stored in a separated object.
    constStructure: a decision on the structure of constants
        Inline: macro expansion on variables. All constants that are represented by variables will be replaced by their value.
        WithInputs: constants are stored in variables within the input object
        Store Unbundled: constants are stored in variables that were directly passed to the function as its own parameter.
        Store Bundled: constants are stored in variables within a separated object
    constRepr: the representation of constants
        Var: all constants represented as regular variables.
        Const: use selected language's mechanism for defining constants. For example, C# has a build-in constant called const, but not all languages have build-in support on constants.

Are these not relevant to Modularity as well? For example, I would think that ConstStructure would have stricter meaning in Unmodular? WithInputs for example, could also perhaps only be relevant to Unmodular.

[JacquesCarette]

I agree that those 3 features are a good starting point.

I agree that the aspects of 'modularity' you mention are good properties that 'modular programs' have. I personally define 'modularity' more simply: it enables local reasoning. If you keep unwinding the consequences of that, you'll recover high cohesion, low coupling and well-defined interfaces.

But also: 'modularity' might be a red herring here! 'modularity' is much more a property of a design than of code. So we might be misleading all Drasil developers by labelling things inside choice Modular. Feel free to rename.

What Choices represents is a set of choices (that's still a good name!) about code structure and code details. Beyond that, our selection of 'choices' is quite ad hoc. So once we add more choices, the natural organization of Choices may well change.

So I would recommend that you rename Modular to Structure. That will allow us to have many different way to 'structure' code, including having basically no structure.

Thinking more deeply about what each choice means / entails may well mean that the feature diagram needs to change too. And then its representation as a data-structure would need to follow suit.

[balacij]

But also: 'modularity' might be a red herring here! 'modularity' is much more a property of a design than of code. So we might be misleading all Drasil developers by labelling things inside choice Modular. Feel free to rename.

I see what you mean and I agree.

With that in mind, I would like to see a fullyModular :: Choices that configures Choices to align with what we think modularized source code would look like. For example, at least the following implementation hints/details:

• Separated input module
• Separated output module
• Separated constants module
• Separated calculations module

Of course, this is assuming that the program always has a "controller" module (the program entry module) that organizes how these things work together. The "default output artifact" (without any implementation hints) would be the "unmodular big blob of code."

So, perhaps we replace data Modularity = Modular | Unmodular entirely! I'll map this out a bit more.

[JacquesCarette]

Agreed on all.