<div dir="ltr">Javier said:<div><br>> I was thinking about that. How to ensure that an inner<br>> step will not use the same register name?<br><br>That's less of a problem than it seems: An inner step would<br>come from an inner pipeline instantiated through an<br>init=foo:bar step, so in that case, a *separate* pipeline</div><div>instantiation handles the registers and stacks.<br><br>It is not possible to pass on anything via neither stacks<br>nor registers between inner and outer pipelines, as they<br>are handled by the pipeline-operator: If you check the<br>code, you will see that the current push and pop operators<br>are part of the pipeline operator implementation - so in<br>that sense, pipelines differ from other operators.<br><br>But in all other senses, they look exactly like any other<br>operator and the only communication that happens is by<br>passing on the operand to the next step.<br><br>So to an outer pipeline, an inner pipeline looks exactly</div><div>like any other operator, and it receives the operand<br>exactly like any other step in the outer pipeline. So no<br>magic there, and no risk of neither register shadowing,<br>nor stack smashing.<br><br>> But, are those registers only for hand-written<br>> pipelines? Do you have in mind any automatic routine<br>> using them?<br><br>(I suppose this is a question for Even, as I'm the one who<br>finds stacks both simpler, clearer and less error prone<br>than registers)<br><br>> If I understood correctly, you also want to move things<br>> from one dimension to the other (from v1 to v3) Does it<br>> make sense to exchange X coordinate with Z coordinate?<br><br>Until now, it has been impossible, through a stack<br>implementation which goes out of its way to *make* it<br>impossible. Jochem presented a case, where a less rigid,<br>and way simpler, single-stack implementation would have<br>saved his day, while still enabling everything possible<br>with the existing four-stack implementation.<br><br>It is not a matter of whether it is a good idea to move<br>things from one dimension to another, it is just that the<br>simpler solution also happens to make this possible.<br><br>Whether to use this possibility or not is not part of the<br>discussion. It is a possibility, and impossibilizing that<br>possibility would require more code, more complex code, and<br>needless second-guessing of "what might be reasonable<br>use cases, now and in all future".<br><br>I believe the current stack implementation emerged by<br>accident: It solved an immediate problem, and hence was<br>considered good enough.<br><br>Had we had the foresight to think this through slightly</div><div>more back then, we would have arrived at the lean single-<br>stack solution, with a syntax mimicking that of axisswap,<br>rather than the unnecessarily complex four-stack solution<br>with a syntax (v_1 v_2 v_3 v_4), not following any other<br>pattern of existing PROJ syntaxen.<br><br>But we didn't, and not much harm done with that: It is just<br>a set of two operators that will live on forever inside<br>pipeline.cpp. But with Jochem's and Even's recent use cases<br>it was clear that the current push and pop operators do not<br>support things that could be reasonably expected from a<br>stack implementation.<br><br>- Jochem initially  asserted that the solution was to make<br>  push and  pop refer to a queue (FIFO), rather than a<br>  stack (LIFO).<br><br>- Even found registers, i.e. an entirely new syntactic and<br>  semantic component more convincing<br><br>- And I have tried to argue that a simpler, leaner stack<br>  implementation would solve both Jochem's and Even's<br>  use cases - and potentially a lot more, by not imposing<br>  artificial limitations<br><br>Three solutions - pick your favorite :-)<br></div></div>