(10-23-2018 04:34 AM)cyrille de brébisson Wrote:  Hello,

SysRpl is a stack based language. Not only does it use a stack for data, but also for state (program blocks)...
GOTOs usually jump from program blocks to program blocks. Which means that they "break/pass" over program blocks boundaries... However, the GOTO code does not "know" that and does not know how to "tweak" the stack as needed... This result in "bad things" (like crossing the streams)...

Modern programming languages that do have goto go to great length to "fix" this, but it is a programming nightmare to do so... And SysRpl is not that "clever", especialy as it does not have a compiler...

Cyrille

(10-22-2018 10:11 AM)3298 Wrote:  Jumping to labels sounds like GOTO to me. This SysRPL command exists but is only usable when the containing program is always loaded at a specific address, which is generally not true for user programs. Even for those few commands in ROM that do use it, it might be problematic as it'll subtly break recall-modify-execute procedures applied to them. (The other commands in ROM don't do that, but a user might get that idea.)
I remember writing a relative GOTO (read this thread, there are some designs by others as well) designed to be used with the on-board SysRPL compiler. It's still pretty fragile because you still can't just have another program modify a relative-GOTO-using program between GOTO position and target (it would throw off the offset calculated at compile time), but at least you can move the program to any memory address without breaking it.

However, there are some terms in your request that confuse me. First: "code" - if you want to switch to machine code and later back to RPL, you don't need labels and GOTO, just embed a code object. Second: "call" and "return" - that's obviously something entirely different from jumping to labels. If you want to call subroutines, just embed them, or if you want to call the same one from multiple places: simply store it in some kind of variable (or even on the stack!) when your program launches, then recall and evaluate it when needed.

(10-24-2018 02:07 AM)BlackMi Wrote:  It says GOTO can only jump to the next address. Could GOTO code jump to any blocks you want?

(10-22-2018 07:09 AM)BlackMi Wrote:  I read the programming in System RPL second Edition. no jump and lables.
Are there some methods to jump to lables and call a function in the code and return in sysRPL?

(10-24-2018 04:23 PM)David Hayden Wrote:  What are you actually trying to accomplish? You may find that words like RDROP or CASE can fill your needs.

(10-29-2018 11:26 AM)BlackMi Wrote:  The problem is I don't know how "data stack" "return stack" and "virtual stack" work to control the runstream.

(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.)

(10-30-2018 02:31 AM)BlackMi Wrote:  This is a loop
BEGIN
condition
WHILE
code
REPEAT

but
::
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?

(10-24-2018 11:10 PM)RMollov Wrote:  

(10-22-2018 07:09 AM)BlackMi Wrote:  I read the programming in System RPL second Edition. no jump and lables.
Are there some methods to jump to lables and call a function in the code and return in sysRPL?

What lables?

(10-30-2018 10:49 AM)3298 Wrote:  

(10-30-2018 02:31 AM)BlackMi Wrote:  This is a loop
BEGIN
condition
WHILE
code
REPEAT

but
::
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?

I think I have seen that code before. You're looking at the programming tricks from Nosy's Readme, right? That's some advanced runstream juggling, so if you don't understand it, start with the simple stuff like merely going up more than one level of secondary nesting (straightforward solution: RDROP at the end of one secondary, so the ; after it pops an older entry off the return stack).

Anyway, the command "case" (and by extension NOTcase which just swaps the effects of the boolean input on the data stack) pops one object off the runstream (here: the command AGAIN), pops one boolean off the data stack, and depending on the value of the boolean it either just finishes (causing whatever is after the object to get executed; here that's whatever "code" gets substituted for), or it pops the topmost pointer off the return stack into the current runstream and then executes the object. The important bit is the return stack popping: that removes the value BEGIN has put there, so AGAIN will use a different one. That will be the runstream pushed by the :: before the BEGIN command (which searched for its corresponding ; and pushed a pointer to what comes after that).
The next question to ask is what AGAIN actually does with the value on the return stack. In an ordinary loop BEGIN simply pushes the current runstream onto the return stack, and AGAIN copies it back into the current runstream without popping it - this is how they work together to create a potentially infinite loop. In this piece of code NOTcase has removed the runstream pushed by BEGIN from the return stack and made it the current one, but before anything from that gets executed, AGAIN gets its chance - it will immediately replace the current runstream again, this time with the runstream of the secondary that called the :: ; embedded in this snippet. The first object in that is RDROP, which gets rid of the runstream AGAIN used but left on the return stack.
In case you wonder why AGAIN and RDROP aren't combined into a single command: That command may exist (it's called SEMI), but because it's an alias for ; it has the side effect of marking the end of the secondary. If the compiler wouldn't complain about the extra ; a few lines below, then using SEMI in place of the first AGAIN and omitting the RDROP would cause the code run on encountering :: to advance the runstream it pushes to the return stack only past that, not past the ; near the end of the snippet.

(10-30-2018 02:27 PM)David Hayden Wrote:  Regarding returning early from a secondary, I wish RPL had a RTN or BREAK command that functioned the same as SEMI when executed, but didn't also mark the end of the composite.