From John in the IRC channel:
'test var :pass 'inc.retro include ; :comp \#3 !test pass \#4 !test pass \#5 !test pass ; comp
@test n:put nl
A short test I did based on the above shows output as the files are read:
x.retro `@Test` 11070076364840 x.retro `@Test` 11070076364992 x.retro `@Test` 11070076365144 x.retro `n:put` 11070076365144 5 x.retro `nl` 11070076365144 x.retro `n:put` 11070076364992 4 x.retro `nl` 11070076364992 x.retro `n:put` 11070076364840 3 x.retro `nl` 11070076364840 c `nl` 11070076364688 c `@Test` 11070076364688 c `n:put` 11070076364688 5 c `nl` 11070076364688 c `nl` 11070076364688
The fields are Filename, token, file handle, and output. This shows that things are definitely not running as expected, which is concerning.
More information from John:
<john_cephalopoda> john Ok, work is over. I saw the backlog.
13:02 When execute() is called, a loop is entered. Main quit criterion is, that the ip > IMAGE_SIZE, which is also met when rp=0.
13:05 It executes the "interpret" word. Then it returns, but since the return stack is not 0 (we enter with depth 6 or 7), it will continue execution from the next address on the return stack. It effectively only reads the first token and then skips back to what it was doing before.
13:06 Eventually it reaches stack depth 0 and returns, which means that the next token is executed.
13:07 I haven't figured out how exactly the control flow goes, but I think that the solution to the problem is somewhere within that exit condition.
Based on the above, I implemented a patch that seems to work. http://forth.works/share/876ac3c9038efc3581bbbb118b4d2f79
It's been committed and I'll do some further tests before closing this issue.