Three Dollar Quill

I'm taking a break from GODEATER prep to reconsider what invariants MOTR's Parametric type will want to track. Here's the general outline I need to work through:

• The Parametric class exists in order to produce Command objects, which produce a set of Facts relating a Command to other Tasks via Inputs and Outputs.
• A Command will have arguments, environment variables, and implicit inputs and outputs (as well as better-behaved values).
• There can be any number of arguments.
• Each environment variable must have just one value.
• Of the Commands produced by a Parametric, no two can produce identical Outputs.
• Of the Commands produced by a Parametric, no two can differ only in implicit Outputs or Inputs.

So, some components are outputs, and need to ensure that the actual parameterization does not vary over any multi-valued label that the output does not vary over.

Some components are environment variables, and the final output must vary over at least as many labels as the environment variable.

Some components are implicit, and if they vary, the final output must vary over those labels in a non-implicit component.

I believe these cases cover the existing fields.

These are handled with the methods as_maximal, as_requiring, as well as a few others.

So, we need fields like:

• "These fields are the only multi-valued labels that the final output can vary over"
• "These fields must be iterated over by the final output [if they have multiple values]" oh no I think I just found a new requirement
• "This output is of one type, and these fields need to be iterated over by an output of the other type"

I'm going to need to ponder how to handle the new requirement I just noticed. Or, technically, maybe it's a relaxation of a requirement? A new requirement of what to accept?

Anyway, I'm done for now, but I'm going to note this stuff down so I know I need to tweak stuff.

Anyway, I should wrap up for now.

Good night.