[PROJ] Make push and pop FIFO?

[Thomas Knudsen]

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 :-)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20240204/f357ef1e/attachment-0001.htm>