Coding 2023-03-19

By Max Woerner Chase

Okay, so, I'm writing this late, so this is kind of "Hey, I should work on this more tomorrow," but...

I'm thinking more about the Parametric rework in MOTR, and the more I think about it, the more I realize that I need to nail down some of the terminology.

I'm right now leaning towards four different kinds of data that can go into a command:

These are all collected into a ParametricCommand, and the usual case for ParametricCommand is that every combination of parameter values corresponds to a single command. However, this is not the case for commands that are supposed to aggregate data from several different versions of some other command.

In order to convert the relevant Parametric values in this situation, the values have to undergo a process currently called "reduction". This selectively overrides the default behavior of combining Parametric values. Now, some variables, instead of duplicating and altering the command invocations, are combined within a single invocation. The way combination is accomplished depends on the type of value.

Thinking about this, we can get the following vocabulary concepts:

The overall desired behavior for Parametric labels is found by looking at the ranges of behavior for:

There are two main things here that relatively less obvious:

The trick to implicit IO is that it doesn't distinguish the command that is actually run, so any selection label used by implicit IO either must be singleton, or must be an iteration label. Otherwise, the same command will get added to the compendium multiple times with different edge data, which is


It's like, there's something that will collide with itself unless separated by something else. I don't think ghost labels is a great name for this concept, but it's better than the weird patchwork I have currently.

So, I think the last thing I need to get parity with what the current system models is something that can handle maps over output values. The thing about output values is that any label that any label that an output value doesn't iterate over can't be a non-singleton iterated label.

I'm not happy with iteration/iterated/whatever yet, but I think this all provides a basis to work with. I'm going to wrap up for tonight.

Good night.