[PROJ] Make push and pop FIFO?

[Thomas Knudsen]

Contrary to you, Even, I find the push/pop duality clear,
non-confusing, and totally in line with the overall
design of PROJ operators. I would, however, for even more
consistency, have preferred a single stack design

Why do I find it so clear? Four reasons:

1. The opposite of "proj=utm" is "proj=utm inv"
2. When a pipeline is executed in reverse,
   "proj=utm" maps to "proj=utm inv", and v.v.
3. The opposite of push is pop
4. When a pipeline is executed in reverse,
   "proj=push" maps to "proj=push inv", i.e. "proj=pop",
   and v.v.

This is clear, systematical and symmetrical - nothing
strange going on here.

If we had a "proj=swap" operator, it would map to itself
when executed in reverse. That may be slightly strange,
but not any more strange than any other mathematical
involutions (e.g. negation, reciprocation, and the identity
operator)

Using named registers, on the other hand, introduces a
non-systematic element, and requires one to invent
arbitrary names for each register.

While these names may be "meaningful" for the pipeline
implementer, they may very well be meaningless for
anyone else.

Also, these registers (=variables) will probably need
to be stored in a dictionary (std::map or somesuch),
and imply an extra lookup for each individual operand.

In Rust Geodesy [1,2,3], I wouldn't care, since the operators
operate on full arrays of operands, i.e. "coordinate sets",
in ISO/OGC lingo, so the lookup is amortized over a large
number of operands, but in PROJ, we actively execute each
step in the pipeline for each individual operand.

Anyway - the lookup may, in practice, be
negligible, compared to all the other things we do
behind the curtains, when executing a pipeline.

But I believe we could clarify and streamline the push/pop
pair by taking inspiration from "proj=axisswap order=...."
in a new implementation or variation, using only one stack,
such that:

proj=pipeline step proj=push order=1,2,3,4 step proj=pop order=4,3,2,1

would implement the no-op, while

proj=pipeline step proj=push order=1,2 step proj=pop order=1,2

would be equivalent to

proj=axisswap order=2,1

As the "order=..." option is disjoint to the set of flags,
"v_1, v_2, v_3, v_4", the new "single-stack syntax" is
easy to discern from the old "four stack syntax".
Also, it would be trivial to implement the enqueue/dequeue
functionality Jochem needs.

As an aside, in Rust Geodesy (RG), I have been
experimenting with a less verbose syntax, which does away
with the "step" and the "proj=" qualifiers.

"step" goes, because it really just signifies the
equivalence of a Unix style pipe connection, which is
expressed more compact and clearly with the vertical bar
"|" syntax also used in Windows and Unix shell commands.

"proj=" goes because it really is a rather misleading term:
It made sense, back when PROJ was purely a projection library,
but for now, where it may introduce any kind of operation,
not just a proj=ection.

Hence, the previous pipeline:

proj=pipeline step proj=push order=1,2 step proj=pop order=1,2

maps to

    push order=1,2 | pop order=1,2

which is significantly more clear and significantly less
verbose, in my humble opinion. And it can be trivially
transformed back to classic PROJ syntax by prefixing by
"proj=pipeline step proj=" and substituting "|" with
"step proj=".

Also, it can live alongside the classic PROJ syntax, since
if neither "proj=" nor "init=" is found in the operator
descriptor, then it must be "RG syntax".

I personally find this syntax handy. In a longer time
perspective, I would like to add support for it in
PROJ (just as I have added support for classic PROJ
syntax in RG). So whatever happens to PROJ syntax, I
would be sad to see it diverge too far and lose the
trivial transformation to/from RG syntax: I truly
believe that RG syntax is both easier to teach newbies,
and easier to write for greybeards, so I think it has
some potential, also outside of RG.

[1] Rust Geodesy: https://github.com/busstoptaktik/geodesy
[2] Overall architecture and philosophy,
https://github.com/busstoptaktik/geodesy/blob/main/ruminations/000-rumination.md
[3] Geodesy from a PROJ perspective,
https://github.com/busstoptaktik/geodesy/blob/main/ruminations/008-rumination.md