[PROJ] Make push and pop FIFO?

[Thomas Knudsen]

> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20240203/2d0246a9/attachment.htm>