Naive question re: RCL variables in 42S & related

[carey]

After using RPL, I’m starting to explore the 42s and related RPN models.

In RPL, after storing a # in a variable (e.g., “A”) variable A can be called directly by name (e.g., “A” can be placed on the stack or used in a program). In the 42S and related models, after storing a # in “A”, RCL A is needed to place it on the stack or to use it in a program. RPN programs generally use a lot of STO and RCL operations. Is there a trick I am overlooking that would allow stored variables to be called directly by name in RPN models or is there no way around using RCL of named variables in RPN due to registers (e.g., reduces variable use and conserves memory.). Thanks!

[naddy]

You have to use explicit STO/RCL operations.

Consider the historical context. Programs started out as keystroke recordings. You press a sequence of keys corresponding to calculator functions and that is recorded. This was slightly enhanced by conditional execution after a comparison, as well as goto and subroutines, which were available right from the beginning. Values could be stored in and recalled from numbered registers. And that was fine when program memory was limited to a hundred instructions. Over time features were added, but programming on the HP-41C and HP-42S is still based on this primitive design. When memory grew to thousands of instructions and it became clear that people were actually writing application programs, HP eventually created RPL as a proper high-level programming language.

[carey]

Thanks Naddy!
Other than the fun provided by the challenge of programming in a restricted environment, are there advantages of 42S RPN explicit STO/RCL variable operations that are still relevant today (e.g., transparency, ease of troubleshooting, etc.)? [Just to be clear, I'm not asking about RPN vs algebraic entry in general - an issue that has been discussed often in the past - just asking about accessing variables via RCL in RPN vs directly by name as in RPL).

[RPNerd]

In RPL, directly using a variable's name causes that variable's content to be evaluated. If the content of that variable is a number then evaluating it is the same as recalling it. If it's a program then that program is run, while using RCL on that variable simply places a copy of the program on the stack without running it.

RPL is all about consistency. Everything should work in a consistent way: you put stuff on the stack and subsequent operations operate on that stuff on the stack. "RCL" is there for all data types for the sake of consistency, but you place the name of the variable on the stack first and then use the RCL function.

[Thomas Klemm]

(10-14-2024 01:32 AM)carey Wrote:  Other than the fun provided by the challenge of programming in a restricted environment, are there advantages of 42S RPN explicit STO/RCL variable operations that are still relevant today (e.g., transparency, ease of troubleshooting, etc.)?

Frankly, I don't think so.
If you're familiar with RPL, you'll probably miss local variables.
Registers and variables are global, which can cause problems.
In general, I avoid alphanumeric variables and try to minimize the use of registers.

So we have a four-level stack, which can be challenging.
But we have LASTX and an automatic copy of T to Z and can use STO/RCL (including arithmetic) with all stack registers.

If you are familiar with Python, this RPN translator might be helpful.
The result can often be simplified, but it gives you a first approximation.

In general, the generated code for a stack-based VM (Java or Python) can be translated to RPN mostly verbatim.
If you like Lisp, you can try Clojure or Hy.

Now I wish you much pleasure in your endeavor.

[carey]

Thank you Thomas!
Your advice about use of registers and variables and the links are very helpful!
I will study the RPN code you've posted over the years as examples of best practices.

Thanks also to RPNerd for helpful comments about RPL!

Carey

[Dave Britten]

RPL has the concept of "name" and "expression" objects. This is what allows you to put a name like 'A' or an expression like '2*A+X' onto the stack and manipulate them further, or evaluate them to get a numeric value. The 42S only supports real numbers, complex numbers, strings (to an extent) and matrices, there are no names or expressions, and thus nothing of that sort that could be put onto the stack or evaluated.

[carey]

Thanks Dave!
Yes, the object perspective clearly explains some of the main differences between RPL and RPN. It is interesting that RPN's reduced object set is both a hindrance and an attraction (simplicity).
Thomas Okken's nice Plus42 adds an equation mode that, if I understand correctly, adds an algebraic expression object (or data type?), offering a sweet spot between traditional RPN and RPL.

[Peet]

(10-14-2024 10:53 PM)carey Wrote:  ... some of the main differences between RPL and RPN....

This is the cause of the confusion. The differences are quite different. RPN is a mathematical notation, RPL describes a programming language.

You can compare RPN to Algebraic-notation or RPL with Keystroke-programming but not RPN wirh RPL.

RPL calculators can use RPN or Algebraic input, keystroke programming calculators can do it just as well (see RPN vs AOS e.g. HP-67 vs TI59).

"Real" programming languages mostly uses named variables and classic calculators usually registers.

[Steve Simpkin]

I would also recommend looking at the book "HP 41/HP 48 Transitions" by William C. Wickes. It is an excellent resource for describing many of the differences between the RPN interface and programming paradigm of the more "traditional" HP calculator models such as the HP-41C series and the newer "RPL" models such as the HP-28, HP-48, HP-49 and HP-50 series. I would start with the section titled "1.2 HP 41-to-HP 48 Evolution".
https://literature.hpcalc.org/items/1614




Edit: The Museum also has a nice introduction to "RPL":
RPL A Platform for Powerful Calculators

[naddy]

The 42S is just the end of the line of a programming model that grew historically without having been designed with a lot of forethought, I dare say. Originally, the calculators only supported real numbers. Offhand I don't know the exact internal format, but given that it was based on BCD, I assume the nibble that held the sign bit had some spare bits that could later be used for a type tag. On the 41C this was used to create a string type that allowed placing strings of up to six characters in stack and storage registers. On the 15C, it was used to create a matrix descriptor type that could equally be placed in registers. The 42S combined those two features and also added a complex type. However, complex numbers, being composed of two real numbers, required twice the storage, which created issues when putting them into storage registers. It's all a bit of a hack, and I mean that in a good sense. What I'm trying to say is that data types were an afterthought. Obviously this is very different in RPL.

[carey]

(10-14-2024 11:21 PM)Peet Wrote:  

(10-14-2024 10:53 PM)carey Wrote:  ... some of the main differences between RPL and RPN....

This is the cause of the confusion. The differences are quite different. RPN is a mathematical notation, RPL describes a programming language.

You can compare RPN to Algebraic-notation or RPL with Keystroke-programming but not RPN wirh RPL...

Yes Peet, you're right and it's always good to emphasize the difference between RPN as a mathematical notation and RPL as an object-oriented programming language. However, in the above discussion of the difference between RPN and RPL, RPN is just shorthand, as is common in the forum, to refer to HP's classic keystroke programmable models vs later RPL models. The alternative is to write out each time something like "keystroke programmable." So in the spirit of RPN (to save keystrokes :), I'll probably still say RPN to refer to keystroke programmable models when the context is clear.

[carey]

(10-14-2024 11:41 PM)Steve Simpkin Wrote:  I would also recommend looking at the book "HP 41/HP 48 Transitions" by William C. Wickes...

Thanks Steve for the great suggestion!

[naddy]

(10-15-2024 12:03 AM)carey Wrote:  However, in the above discussion of the difference between RPN and RPL, RPN is just shorthand, as is common in the forum, to refer to HP's classic keystroke programmable models vs later RPL models.

And, of course, by the time of the 41C and 42S it wasn't literal "keystroke programming" any longer either.

[carey]

(10-15-2024 12:22 AM)naddy Wrote:  

(10-15-2024 12:03 AM)carey Wrote:  However, in the above discussion of the difference between RPN and RPL, RPN is just shorthand, as is common in the forum, to refer to HP's classic keystroke programmable models vs later RPL models.

And, of course, by the time of the 41C and 42S it wasn't literal "keystroke programming" any longer either.

Good point!

[Thomas Klemm]

(10-14-2024 06:16 PM)Thomas Klemm Wrote:  If you like Lisp, you can try Clojure or Hy.

Some related links:

• Python to FOCAL Compiler
• Python to RPN converter
  

And here's an example of disassembled byte code from Hy:



Which can then be translated to RPN/FOCAL:

Code:

LBL "CIRCLE"
STO 00 ; r
RDN
PI
RCL 00 ; r
2
Y↑X
*
RTN

---

Addendum: This is the result of the current version 1.0.0 in try-hy:

Code:

import hy
------------------------------
Hy 1.0.0 (Afternoon Review) using CPython(main) 3.12.1 on Emscripten
=> (import math [pi])
from math import pi
None
------------------------------
=> (defn circle [r] (* pi (** r 2)))
def circle(r):
    return pi * r ** 2
None
------------------------------
=> (import dis [dis])
from dis import dis
None
------------------------------
=> (dis circle)
dis(circle)
------------------------------
  1           0 RESUME                   0
              2 LOAD_GLOBAL              0 (pi)
             12 LOAD_FAST                0 (r)
             14 LOAD_CONST               1 (2)
             16 BINARY_OP                8 (**)
             20 BINARY_OP                5 (*)
             24 RETURN_VALUE

Conclusion: While the generated byte code for Python 3.12 is different it can still be easily translated to RPN/FOCAL.