SASTask sorts all its components by variable number first, when created.

If reorder_variables or filter_unimportant_vars are specified, the order of 
variables might change. 

The components are not sorted again, so the outputted sas file is not sorted, as 
specified in the comments. Example gripper action (first action, prob01):

begin_operator
drop ball1 rooma left
1
0 0
2
0 3 -1 0
0 1 0 4
1
end_operator

The culprit is the variable reordering in variable_order.py. Fixing the issue just requires a small adaptation of VariableOrder._apply_to_task(...). But I would first wait for the outcome of our meeting on Friday to know what we actually want.

We also have such operators with unsorted effects in the TranslatorOutputFormat documentation of the wiki, so this would need to be adapted and documented there as well.

It's probably the easiest to just sort at the end and get rid of the issue. But whatever we require and exploit for the input to the search component, we also need to maintain through all task transformations applied there. So it might be worth looking a bit deeper into what we actually need. For only keeping the translator output deterministic, it is not necessary to sort.

The requirements defined in validate stem from 2015, so a lot of them might no longer be necessary. The question is, how to figure this out without reading through most of the search code. Moving along the accesses to the task proxies might be a good start.

To add to what Michael wrote:

- This is a bug because we say it's sorted in the detailed comments in sas_tasks.py, which we also publicly reference on occasion (e.g. on Discord), primarily when people want to generate SAS+ tasks manually.

- I remember code in the search component (which may or may not still exist) that depends on conditional effects on the same variable being consecutive in the output. This is a weaker condition than the sorting we currently promise, and this might be a promise we actually hold. (It looks like we generate the sorted form, then prune and renumber variables. This destroys ordering, but not consecutiveness of effects on the same variable.)

- We can potentially resolve this in several ways, either by sorting at the end (in which case I think we can get rid of the sorting earlier) or by relaxing our specification of what the output of the translator looks like.

- This is related to the "search component should check validity of its input file" story that we considered for the last sprint. I don't know if/where the current state of this lives on the tracker.