[Txr-users] Fixing quirky behavior between @(trailer) and @(accept).

[Kaz Kylheku]

Hi All,

There is a quirk which occurs when the material subordinate
to a @(trailer) decides to bail out a surrounding block
with @(accept).

This is easiest to illustrate with an example:

@(block)
@  (trailer)
@line1
@line2
@  (accept)
@(end)
@line3

Assume the input is

1
2
3

TXR ends up with these bindings:

line1="1"
line2="2"
line3="3"

That is to say, the @(accept) bails out of the block, and transmits
the data position as part of the successful result. So after the
block, @line3 matches the third line.

But this appears to contravene the semantics of @(trailer) which is
not supposed to advance the position.  It turns out that @(trailer)
works that way only if it succeeds normally, not if it is terminated
by a non-local control transfer such accept. In that case, the
result propagated by the accept dominates and trailer has no say
in the result.

I'm experimenting with a fix which changes that: the result
I'm getting in my sandbox is now this:

line1="1"
line2="2"
line3="1"

As you can see, after the block terminates successfully due
to @(accept), the position is back to line 1, and so line3
captures "1".

The position will not advance into the material matched under
@(trailer) but of course the bindings are retained.

How it works is that @(trailer) establishes an unwind-protect
point. When the @(accept) intiates unwinding to the surrounding
block's exit point, the unwind-protect code set up by trailer
looks at the current exit point and realizes that a block return
is taking place. It then goes into the exit point block and
rewrites the return value that has been placed there: the position
is replaced with the trailer's position.

To make this work I have to introduce the idea of a block return
protocol, which is an additional symbol that identifies the situation
to which a block return belongs. Without this, @(trailer)'s
unwind protect cannot be sure that it's looking at a block return
initiated by accept.

Cheers ...