Three Dollar Quill

Okay, so. I should have expected that I wouldn't be up for much today, but whatever. Let's take a look at the code.

I define four sets of labels that control whether a parametric metadata is valid for various purposes. There is an additional generated set. To extend the scope of validation I need to:

• Verify the intended usage of each set.
• Update the names to use a clearer metaphor.
• Check on the semantics of the helper functions.
• Make any required fixes.
• Track additional sets.
• Create further invariants.

Let's look at the sets:

• provided_labels: "the Parametric will iterate over these labels."
• required_labels: "the Parametric needs these labels to be iterated over."
• handled_labels: "the Parametric can handle these labels being iterated over."
• multivalue_labels: "the Parametric cannot handle labels besides these being iterated over." (Technically, it's fine if the other labels don't contain more than one value. I think. At least, it works like that in the code, probably.)
• expected_labels: "the minimal set of labels expected in the final product." (the definition is provided_labels | required_labels)

"Product" is actually kind of an interesting word there, because the idea is to form a cartesian product over all of the selections. I don't know if I can work that in. Although, calling them "factors" might help. Or it might not.

Anyway, it's getting late, so I'll have to pick this up later. First, I want to try to explain why there are all of these different sets.

• A "provided" label refers to the label's value correlating with an explicit value in the final result.
• A label that is only "required" correlates to a value that is implicit in the final result. This is acceptable in intermediate calculations, but leads to problems if it gets all the way out, because that situation corresponds to Cmd objects that only differ in their implicit IO, which is broken sometimes, and I don't think corresponds to any desirable state, so I try to forbid it.
• A "handled" label might not be iterated over by the metadata that contains the set, but if other metadata does iterate over that label, then that situation is handled gracefully.
• The set of "multivalue" labels, if present, represents a hard limit on the labels that the metadata will allow iteration over. This addresses a similar issue to the "implicit" stuff above, in that multiple Cmd objects should not produce the same output artifact.
• A label is "expected" if either it is explicitly iterated over, or if something else should iterate over it, even though this metadata doesn't.

That's a lot to unpack; I'm looking at this and kind of wondering if sorting this stuff out would be a good use case for formal methods. For now, I've written these field names down and suggested clunky but descriptive new names; the goal from that is to come up with something better than either, in each case. And now that I've done that, I'm going to get ready for bed.

Good night.