> stack swap, flip: sorry but my own imperfect brain of a > programmer not having coded in Forth, I will have a very > hard time to remember what they do exactly without > referring to the doc :-)
But I believe you have programmed in assembly, which is exactly the same. "swap" swaps the top-of-stack with the second-of-stack, "flip" was Jochen's invention of (essentially) doing a swap, while behaving as if the operand is the top-of-stack. I do not necessarily find it a stellar idea, but in the use case presented by Jochem, I acknowledge the elegance. Otherwise, these instructions are fundamental computational paraphernalia and come with the advantage of not having to invent register names for something living transiently. Named registers make sense for cases hand-written by people with sufficiently deep insight to invent meaningful names for the registers. In the auto-generated case, on the other hand, we will have to rely on e.g. UUIDs, which certainly does not provide a nice reading/debugging experience (as you also point out indirectly in your final comments). Hence, nice use cases for both register and stack based approaches. And as the stack based approach (although in an unfortunate shape) is already part of PROJ, I assumed that most PROJ users and developers would be familiar with that way of thinking > Why not having 2 separate operations, since (save,into) > and (restore,from) are mutually exclusive parameters. To reduce API sprawl (for a sufficiently abstract notion of the concept "API"): The major part of PROJ operators are simply implementations of "something out of either Snyder's book or EPSG Guidance Note 7-2", i.e. something that takes a coordinate as input, and does some totally step-local thing with it. Saving and storing (pushing and popping) operand elements, on the other hand, are kind of modifiers, that do not do anything particularly interesting by themselves, but they modify the response of the next operation, by dragging in context from potentially many steps away. In other words, they break the locality/linear control flow of the pipeline. So having a special set of top level operators (proj=stack, proj=reg(ister)) is both a way of flagging to the reader that "here be dragons", and a way of encouraging a somewhat more comprehensive and cohesive way of documenting the bastards, by making them fit under a common conceptual headline. You might argue that in that case, it would be preferable to have just one top level operator for breaking the flow. I would agree with that, but my imagination was not up to inventing a sufficiently general concept, without steering directly back in the mess I was trying to sketch a way out of :-) Finally, let me express my huge appreciation for you taking time to discuss this. I find it fascinating to observe that our notions of "what is natural and elegant", and "what is bolted-on and kludgy" are so different (perhaps even close to being orthogonal!). It probably mostly underlines the fact that "communication is difficult", but maybe also that both approaches may have their advantages
_______________________________________________ PROJ mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/proj
