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