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