50g multiple output

[DavidM]

You're getting some great advice here from multiple sources. I'll add my take on a couple of specific issues.

nlj has hinted at something in one of his responses that I'd like to emphasize: everything in RPL is case-sensitive. So variable 'a' is not the same variable as 'A' (globally or locally). I suspect you probably already know that, but I just wanted to emphasize it because it can definitely make bug-finding more difficult if you've mixed the case of variable names in different parts of the program.

The User RPL concept of local variables (and the mechanics of using them) takes a little time to understand. The syntax used to define them isn't as "RPN-ish" as many would like, but I suspect was chosen in an effort to improve readability more than to fit into the traditional RPN "operand(s) first then operator" model. Just keep in mind that there are 4 distinct parts to any UserRPL local variable context:

1: objects on the stack that define the initial values of the named locals
2: the "→" operator
3: a sequence of local variable names
4: a single object that will be executed/evaluated using the named locals

That single object in item 4 above has to be one of two things: a program (enclosed in brackets « »), or an algebraic (enclosed in tic marks ' ').

The local variable names listed in item 3 above only exist for that last object. Anything following that object in your program won't ever know that they even existed, and will treat any references to those names as global variables instead. So the context of the locals both begins and ends within that single object defined in part 4.

Consider some examples. In this situation, I have created 3 global variables (A B C) and stored the values (4 5 6) into them. Then each of the following programs is executed:

Code:

o1
«
   1 2 3
    →
   A B C
   « A B C * + »
»

o2
«
   1 2 3
   →
   A B C
   'A+B*C'
»

o3
«
   1 2 3
   →
   A B C
   « A B C * + »

   « A B C * + » →NUM
»

o4
«
   1 2 3
   →
   A B C
   'A+B*C'

   'A+B*C' →NUM
»

o1 result: 7. Note that the local variable context supersedes the global variables which are already defined.

o2 result: 7. Same result as o1, same reasons.

o3 result: 7 34. Note that the exact same source code has two very different results. The local variables went out of context after the first sub-program was executed, so the same variable names in the following statement (which looks the same, but actually isn't) now refer to the previously defined global variables instead of the locals.

o4 result: 7 34. Same result as o3, same reasons.

The use of locals in RPL programs definitely has a learning curve, but the advantages in program clarity and the reduction of "stackrobatics" they afford is very real. You've got a good start on this, keep it up!