Can 50g sysRPL jump to lables?

[BlackMi]

(10-29-2018 01:36 PM)3298 Wrote:  That doesn't answer what you're trying to do.

The runstream consists of the remaining objects or commands in the currently executed secondary. At a low level, it's represented by a simple pointer into the secondary. When another secondary is entered, the runstream is pushed to the return stack (basically a stack of runstreams) and replaced by the contents of the new secondary, and when it's exited again, the return stack is popped back into the runstream. The normal way to exit from a secondary is the SEMI at the end, but some commands do this earlier, e.g. ?SEMI (which returns when the value it takes from the data stack is TRUE, otherwise it does nothing). This is documented as "dropping the rest of the runstream" or simply "dropping the runstream".
The runstream can also be "popped", which means the command or object after the command doing it is taken, the runstream pointer is advanced past it, and then something is done with the object or command (the simplest case: pushing it onto the data stack, which is what ' does).

Apart from saving where secondaries were interrupted for calling another secondary, the return stack is sometimes also used for temporary storage (e.g. OBJ>R_ and R>OBJ>_), or for certain control flow commands (e.g. BEGIN, AGAIN, and friends; but not DO and LOOP, those use yet another stack to save their loop environments). In both cases, make sure the return stack level won't get used as a runstream, or bad things will happen.
A particularly creative use of the return stack is the combination of >R and a loop containing ticR (possibly surrounded by two instances of RSWAP if using indefinite loops) to efficiently iterate through a list. >R pushes a composite object from the data stack (secondary, list, or similar) onto the return stack in such a way that its contents would get executed between returning from the current secondary and continuing whatever called it; ticR tries to pop one object off the newest runstream on the return stack (not the current runstream) and reports success or failure as TRUE or FALSE.

The data stack is what you see in the display. It doesn't have a direct influence on runstream and return stack, but many commands manipulating the runstream or the return stack take input from the data stack, or they leave output there.
The virtual stack is completely irrelevant here, it's a stack of data stacks. I know of no commands dealing with both the virtual stack and return stack / runstream. Same for the stack of temporary environments and the stack of do-loop environments. (SEMILOOP may be filed under the DO-LOOP category, but I think that command isn't even a SysRPL entry point; if it's an ASM one, the "loop" part would refer to the "return to RPL" procedure instead of definite loops in SysRPL.)

This is a loop

Code:


BEGIN
    condition
    WHILE
    code
  REPEAT

but

Code:


::
    BEGIN
      condition
    NOTcase AGAIN
      code
    AGAIN
  ;
  RDROP

does the same thing.
What happened in the process? Should not the first AGAIN loop to the BEGIN running the condition over and over again?