(2020-05-28, 15:53)Daniel R Wrote: This syntax also does not allow to edit instruction easily. Suppose you move some subassembly into a new subfile. Then you would have to think whether to edit this tuples or not. That is manual editing, which is error-prone and time-consuming. I suggest marking the target step instead of hard-coding numbers in the first step.
On the other hand, at least it's edit-able. If you get into recursive IDs, then manual editing—or rather, user comprehensibility—get a bit muddier.
But why would it have to be manual editing? There's nothing about this idea that says it has to be; I'm always assuming that editing programs would (continue to) provide a good user interface to the underlying commands. At the same time, it is a goal to have the syntax be more human-digestible than the current system of buffer exchange. And of course, manual editing will still always be an option; and if that's the case, I think recursive IDs would be far more error-prone and time consuming to manually edit than simple command line parameters.
Be that as it may, it does seem clear that ID'd command pairs are necessary once we get into submodels, so the tuples would probably never become necessary. (Only unless you wanted to offer the option of a simpler syntax for when recursive IDs aren't necessary. To that end, the ID itself could be an optional parameter; if absent, the program would use the command line parameter to release the float, and if present, the software would automatically generate a paired UNFLOAT command and use that instead. Although that may be a bit like installing a steam engine in an automobile as a fallback for the internal combustion engine!)