[antlr-interest] Bug in application of rewrite insertAfters?

[Conrad Hughes]

Hi all,

I've run into a bit of a problem with concatenation of insertions during
rewriting, and think that the problem may be due to an asymmetry
resulting from the transmutation of insertAfter(n, x) into
insertBefore(n+1, x) in TokenRewriteStream...  The comments before
reduceToSingleOperationPerIndex() state that

     *  I.i.u I.i.v                             combine: Iivu

.. if two insertBefores occur before the same index i with text u and v
respectively, then they're glued together second-first, v-u, *not*
first-second.  This means that an insertion before a token applied in an
inner rule is glued more tightly to the token than an insertion applied
in a containing rule --- or, temporally, that in a sequence of
insertBefores, the first one will remain adjacent to the token, the
second adjacent to the first, and so on.  Here's an illustration, now
writing iB (for insertBefore) instead of I:

  iB.1.x iB.1.y iB.1.z -> iB.1.yx iB.1.z -> iB.1.zyx

This makes sense, I think.  However, the reverse situation is true of
insertAfters: if a similar sequence of insertAfters following the
preceding token are processed, we get (iA=insertAfter):

  iA.0.x iA.0.y iA.0.z ->
  iB.1.x iB.1.y iB.1.z -> iB.1.yx iB.1.z -> iB.1.zyx

.. now, where we'd have liked the first insertion to be closely glued to
token 0, in fact it's been closely glued to token 1 --- and instead of
the desired concatenation resulting in something equivalent to iA.0.xyz,
we have iB.1.zyx = iA.0.zyx, the reverse of what I think we'd hope for.

Does this make sense?  I saw a similar question asked in November 2008,
but there was no response...

One solution I can think of would be to give InsertBeforeOp two text
fields, one left-accumulating (for insertAfters) and one right-
accumulating (for insertBefores), and these could be joined together
when final rewrite processing is applied.  It might be possible to do
something smarter by collecting insertions last-first instead of
first-last, but intuition suggests that that would involve substantially
larger changes to the code.

Conrad