What would you prefer: RPN or RPL?


Full disclosure: This is for some decision making related to OpenRPN.

The reason I have posed this question is that I'm curious if there's much real interest in a RPL based calculator. While it may not be perfect in every way, the 50g is a reasonable option for anyone needing a graphing calculator that has RPL program-ability. When I need a CAS I use a computer, and the same is true for most function plotting, running statistics on huge data sets, etc. From a personal standpoint my dream machine is what the 42s could have been if engineers weren't forced to hold back to prevent it from cannibalizing 48g sales.

One loosely proposed concept has been brought up under the title of RPN+ and serves the purpose of an extended version of what we already know. User definable or otherwise unlimited stack would be included. After the core functions are implemented, all others could be written in a scripting language (options such as python and lua have been mentioned.)

The other option is *fix, which is effectively sysRPL Forth.

If you have some other idea, please put post it. Input is needed so we can feel more confident in our choice of direction.




I vote for RPN | RPN+ too. I use a RPL machine (HP-48SX) for my work calculator, but I would rather have an expanded RPN+ for a new calculator.


n.t.= No Text


I don't know about RPN / RPL, but I think I'm losing interest in getting any more calculators without a CAS. If a CAS implies RPL, then I'm in the RPL camp.


RPL forever :D

And HP50G specially.


I'm hardly a programmer any more, but I would hate to see the richness and depth of RPL lost when building an "ultimate" calculator that is to rise above the 50g. RPL is iconic in HP history. If sysRPL FORTH is truly implemented in the classical tradition of the FORTH language, where you build new objects as a combination of existing objects, it would certainly be a powerful way to build and share libraries. That would be a positive vote for *fix.


Everything we have considered thus far includes FORTH like ability to build commands from a core command set. No matter what, it will be possible to very easily make this hardware into any type of calculator you want. If people just want RPL, it seems that emulating saturn would be the easier route. Commands will not even be limited by the system we implement as other executables can be written.


For your project, make the HW capable enough so it can be both: RPN+ and RPL+.

If you can, give it WiFi for really convenient sharing abilities and more.

CAS. A calc without multiple visible lines and visible data types such as arrays and infix expressions, isn't really a suitable base, I think.

So, I'd say, yes, you need an RPL-style machine if you want to offer a CAS.

I'm currently implementing a CAS for my project, ND1. It's effectively Mathematica, via use of the WolframAlpha API. How cool are Mathematica results in an RPL calc? Very...

As I mention in your project's forum, if you make this machine a suitable base, I'll work on making ND1 available for it. If you add WiFi, it will have a Mathematica-based CAS.

[EDIT: To clarify, I'm suggesting a system that's open enough to "boot" into multiple calculators. I added more thoughts to the thread in the openrpn forum.]

Edited: 20 Oct 2011, 4:02 p.m.


If you can, give it WiFi for really convenient sharing abilities and more.

For a device like this, Bluetooth would be the better choice: easy peer-to-peer networking and low power consumption.

RPN only. Take it one step at a time. If an RPN approach is ever accomplished then do RPL & Forth for those fanatics that need it.


I guess I'm not seeing much of a difference in RPN vs RPL. I sort of see RPN as just the keystroke version of RPL (and hence a bit more limited). In fact, on the HP48 and similar systems, if you wanted to do keystroke programming, it could be done provided you start with << and end with >> -- everything in between may as well be keystrokes. The only other minor difference is how ENTER is implemented.


The only other minor difference is how ENTER is implemented.

And STO...


And GOTO. (I do wish RPL had GOTO)

Edited: 20 Oct 2011, 6:13 p.m.


And GOTO. (I do wish RPL had GOTO)

So do I - and LBL. My biggest pet peeve with RPL is the lack of GTO and LBL.


Give me a BREAK!


Give me a BREAK!

And a PAUSE (but the kind that accepts keystrokes while pausing, otherwise we cannot play Lunar Rocket Lander properly)


Which, of course, is first priority ;-).


Which, of course, is first priority ;-).

Yes! And second priority is a short and simple manual for me. I'm spoilt by 20+ years of Macintosh usage and really don't want to waste my time with anything that can not be mastered intuitively. Ten pages maximum for the manual (8 of which the list of functions :-) , not more than two for using and programming) and I buy it!


Hi Maximilian. To me the Mac user interface isn't intuitive but rather it's consistent. It works the same way from software app to software app year after year. For example, dragging a disc to the trash can to eject it isn't intuitive at all but it's worked that way for many years.



How much shorter than this RPL on wikipedia do you want the manual to be?

Honestly, I don't understand why people say that RPL has a steep learning curve. The language is about as easy as it gets.

Mastering the 700+ commands in a 50g (or other RPL machine) is another matter, but you don't need any of them to comprehend, and use, the language.

The command set isn't there to intimidate, either. It's there for you to pick up something when you need it, and save you from wasting time on reinventing the wheel.


I don't think that it is difficult so much as different. From my perspective, coming at it as a programmer, it is a relatively easy language with a lot of power. Many people seem to miss that it *is* keystroke programmable (just place your keystrokes between <<>> and you are set). Maybe the looping constructs are more involved but with that added complexity comes power. And they really are not that hard to master. However, I would still rather have FOCAL or RPN for quick and dirty solutions and RPL for more involved, fully developed, applications.




The Wikipedia article does a great job of summarizing the main commands on RPL.

Also check out my RPL blogs on Eddie's Math and Calculator Blog for a summary of some of the main commands.


You can do all that with RPL. You can also have temporary variables that span across multiple subroutines (i.e. temporary global variables) by prefixing them with the left arrow (e.g. <-p)

<< subprg1 >>
<< subprg2 >>
<< subprgn >>


s1 s2 ... sn


@ main routine goes here

@ call a subroutine with:

@ do a GOTO with:

@ pause and wait for keypress with:


I'm not familiar with how BREAK works in RPN... does that just exit the current loop? Or does it kill the program?


Cool - up to now I had to store the subroutines as global variables and purge them in the end. I have to try this! Thanks!


No need for BREAK in RPN, a GTO just does the job nicely. Cleanup of loops is just by reusing their counter register(s).

BREAK would be a nice addition to RPL because it lacks a clean way to exit a loop early if some condition becomes true. This is common practice in languages like C or Java.


I made a clean exit from a FOR NEXT loop by bumping up the loop counter to the exit value when I determined there was no point continuing the loop.


Isn't the loop index precomputed and immune against later modifications in RPL? What about a loop without an index variable?


From the AUR

FOR takes xstart and xfinish as the beginning and ending values for the loop counter, then
creates the local variable counter as a loop counter. Then, the loop clause is executed; counter
can be referenced or have its value changed within the loop clause.
NEXT increments
counter by one, and then tests whether counter is less than or equal to xfinish. If so, the loop
clause is repeated (with the new value of counter).

By loops with out an index do you mean 'while' and 'do until' loops? in both of these cases these loops execute until some logical condition meets the exit criteria. While I have not explicitly tried this in RPL I would expect you should be able to have a compound test and one of the terms can be an exit flag that you could set or clear when you determine that you wish to exit the loop early.


I stand corrected, RPL allows the modification of the loop counter and the increment can be taken from stack each time. There is a loop construct with no visible counter in RPL (START/NEXT). But there is also a variant with a variable increment. All these loops (except START/NEXT) can be exited early by modification of the increment or the loop counter but you still need an IF block to skip any unwanted statements in the block. BREAK would make things easier.


Yes but even for break you need to make some kind of decision to get to the break in my case I did the test to see if it was worth continuing and all the code for the loop was under the THEN term and under the ELSE term I bumped up the loop count for early exit. I don't see how a BREAK command would make that any better.


A break is convenient to immediately leave a loop w/o enclosing the remaining code in a conditional statement, as it would be necessary when bumping the counter. Of course, one can live without BREAK, but it gives more clearly arranged code when using it. Java is quite stripped down compared to C++ in some respect but contains everything one needs. It's remarkable that break has been left in and that it's widely used.


In Java, break has even been extended to take a label. This way you can break out several loops at once which is otherwise a mess. The labeled break isn't a goto, you can just 'name' the loop to break.


In Java, break has even been extended to take a label. This way you can break out several loops at once which is otherwise a mess.

I still remember the good old BASIC times ;-) where you could simply go FROM wherever you want TO wherever you want with a GOTO!
Ok, many called this "Spaghetti code", but nevertheless this was quite comfortable (and BTW, every assembly code works exactly the same way) ... :-)



Leaving a FOR/NEXT loop this way leaves an open control structure in memory. :-(


Leaving a FOR/NEXT loop this way leaves an open control structure in memory. :-(

Well, first I don't think this would be a problem at all (you'll certainly not do it thousands of times ;-)), and then you could always set the loop-variable to the endvalue and GOTO the NEXT statement.

Plus, don't you still have to put an IF around the following code, until the NEXT/STEP?

'fraid there's no substitute to BREAK.


Yes you do but it would seem to me that in order to determine if you should exit from a loop early, you would need to make some kind of a decision within the loop. I just don't think the lack of BREAK is such a big deal.



for i:=0 to 1000
if condition
if condition2

Yes, you can rewrite this to

for i:=0 to 1000
if condition
if i < 1000 && condition2

but you have to have knowledge of the end value and you need to insert one additional IF, or condition for an existing IF, per break.

It looks bad and it introduces extra computation. What's more, if the end value should change, you have to maintain your end value update and code exclude IFs, or your code will (spuriously) fail.

This wouldn't be so bad, if breaks were rare. But running over a domain, checking for something, and doing an early exit is the life-blood of basic search algorithms, and happens all the time.

The RPL designers tried to keep things simple, and in this case maybe a little too simple.

CONTINUE is missing too...


KILL will kill everything that's running; if a parent program calls a subprogram that has KILL in it, both programs are killed.

People have pointed out that a language can be turing complete without GOTO, which is true; in principle, you could just be very careful about your structures. However, we are talking about hand-held calculators here, and I think for that application, it's important to be able to write programs on the fly. I've been in situations where a slight revision to a program would necessitate massive changes to the structure (adding many more IF THEN blocks throughout) when a simple goto or break would have done the job.

It is, by the way, possible to do loop breaking with error trapping / custom errors. I think this is the standard way it's done now. I think a built-in BREAK command would be more elegant.


Agreed. And that's why I (just recently) put it into RPL+.

Along with IFTB ("if-then-break") and CONTINUE and IFTC ("if-then-continue").


I tried your suggestion Han but I am having trouble getting the program to execute.

An example:
The goal of this program is to give a menu of 3 options: return the principal root of a number (F1: RPN), return all the real roots of a number (F2; REAL), and return all the real and complex roots of a number (F3: ALL).

<< { { "PRN" << XROOT ->NUM >> }
{ "REAL" << -103 CF SUB1 EVAL >> }
{ "ALL" << -103 SF SUB1 EVAL >> } }

I get "CF Error: Undefined Local Name" error when I try to run the REAL option.

I get "SF Error: Undefined Local Name" error when I try to run the ALL option.


It looks like the local variable SUB1 is not accessible to the routine tied to the options "REAL" or "ALL". You can try <-SUB1 as the local name. If that doesn't work you need to define a global variable for SUB1. It depends on the inner workings of TMENU. You should create a subdirectory for the variables and the program to avoid cluttering HOME.


I have been using global variables and purging them at the end:


<<   <<subroutine goes here>> 'SUB1' STO
(Main program)


You didn't try the backwards arrow? This introduces a special type of local variable with extended visibility. (Don't ask for details!)




RPN every day of the week and twice on Sunday.


And if you want a scripting language to go with that, try Raven.


Algebraic stack.


RPN, but with more than 4 levels.


RPN, perhaps with a well designed complex stack. Four-level stack is fine for me, with classic HP behavior.


RPN, please.


RPL is a very small, very efficient programming environment. The compiler and decompiler are pretty simple, so it's easy to write programs in RPL on the calculator.

On the down-side the syntax is not very intuitive.

I think many of the design goals for RPL don't really apply any more, so I'd vote for key keystroke programmability of RPN and a more modern scripting language as you mention.


I think many of the design goals for RPL don't really apply any more

I agree. Is not it the reason why HP lost education battle to TI?


I very much doubt RPL is the reason HP lost the educational market.

Cost is a big one. HP was never cheap.

RPN is probably the second. When I was at school (early 1980's) the teachers had at most half a clue as to how to calculate in RPN but they really weren't sure. The fight was lost here before I finished high school -- there were only two of us with HP calculators at that stage. Everyone else used CASIO, actually I did too since my 34C was broken & I bought a 602P.

A few more at university (late 1980's) used RPN but it was still in the minority. When the 28C came out nothing really changed.

- Pauli


There isn't wide-spread instructional materials of RPN/RPL - not it was promoted as much (I think) compared to algebraic operated calculators.


I have several thousands pages of RPL documentation on my laptop, from deep down technical to user level and the internet is full of RPL instructions (and RPN).

So what is missing in your opinion ?

The real problem is that people/user do not read anymore. Which, as a quid pro quo, leads to declining manuals which are read even less which ...

I will be comming out with a help for *all* commands ASAP as shown here

HP 50G Full Command and Function Reference incorporated into the O.S.

which might be helpful as a short reference *but* for sure it can not overcome a lack of missing fundamentals which is the primary function of books.




By the way: For years I have been saying that the success of a machine targeting at professionals depends on the documentation/ease of use that comes with it.

But of cause that is contradictory to a company looking at short term profit only.

Edited: 23 Oct 2011, 5:02 p.m.


I was in high school in the late 70's. Everyone had a calculator, but most people used TI's even then. A few - perhaps 5% - used HP. So what has really changed?

I think it's the fact that the TI-83 is basically built into the textbooks now. My daughter, along with everyone else in her class, was required to buy one in 6th grade. The calculators are built into the books, and the lessons, and getting the teachers to change would be a lot of work.

I think this is actually one place where HP could very effectively leverage us, the user community. We could create HP-versions of the specific calculator lessons/exercises in specific textbooks. So if a teacher uses textbook XYZ, he or she (or the student) could go to a website and download the HP version of calculator lessons. Now if the teacher says "do the exercise on page 234," the enlightened HP student could just flip to the appropriate "translation" in their handy HP packet.


RPL - and please NO CAS :-)

I guess there are two domains:

Education: They are already gone to algebraic, no one is getting an RPN/RPL calculator - only if he/she is a rebel :-) And there are tons of calculators with CAS for them - because you are not allowed to have a computer on an exam, CAS might be good for them...

Grown-Ups: Like me, who need a calculator at work, for light calculations (some cosine here an there, perhaps some small apps for quick calculations in a meeting, etc). For everything I need more than 30sec to enter (that includes 10x10 matrices) I use a computer, as it is faster overall.


I assure you that a CAS can be useful to grownups.


Yes, I use it all the time - on my computer :-)

Of course you are right, I was just a bit exaggerating...






Another vote for RPN


Both :)? I'll take RPN as my preference.


Is there a neither option? Algebraic is the way to go.



Our version of RPL, *fix, is probably the best option for neither. It functions in prefix, infix, and postfix. Here's a link to a java implementation if you want to see it in action:




No advantages to the RPN method of entry?

Or you mean just for the user programming language?


Algebraic is the way to go.

Trolllllllll... :)


Is there a neither option? Algebraic is the way to go.

What is this "Algebraic" thing that you speak of? I am not familiar with it.


"You keep using that word. I do not think it means what you think it means."


It comes from a combination and contraction of two words:

  • Algae
  • Braille

It refers to an ancient and little used form of written communication that lays out a thick sheet of pond scum and then glues blood sucking leeches into a variety of positions to render the letters. The writing is read by placing your finger tips onto the slimy surface and feeling the leeches bite into you.

One has to be wary however, an algebraic rendition of Tolstoy's classic War and Peace is very likely to render the reader unconscious, if not dead, due to blood loss.

Additionally, unscrupulous authors have been known to practice bdellotry before affixing the leeches into position, thus causing a greater level of blood loss amongst their readers.

Finally, the pond scum is very likely to infect the reader with a variety of nasty bacterial diseases.

- Pauli


Heh heh, what did you read last?


The last book I read was The Stainless Steel Rat Sings the Blues by Harry Harrison.

- Pauli


Hi Paul,

I thought it would be from The Devil's Dictionary by Ambrose Bierce,

and also had consulted the American Heritage Dictionary for its origin, that was also interesting :-)

[Arabic, al-, the + jabr, bone-setting, restoration (from jabara, to set (bones), force, restore.)]



I wasn't aware of The Devil's Dictionary. Interesting.

The real definition is a bit of a surprise. Quite unexpected -- not that it comes from the Arabic but what exactly it does come from.

I prefer the one I made up :-)

- Pauli


Words containing the syllable "al" are suspects having Arabic origin: Gibraltar, Andalusia, Almeria, ...


Having fun with the online etymology dictionary.

Alcohol, albatross, alcove, alchemy, alembic and algebra all either originated in Arabic or passed through it on the way to English. Alderman, aleatory, aleph, ale, alert, algae and alien are all from sources other than Arabic.


I said I wasn't surprised that the word had Arabic origins.

I was surprised at the meanings of the words is came from.

- Pauli


I always wondered.

Thanks for clarifying the issue scientifically.


RPN if OpenRPN is to be a non graphic calc (43S)



For a calculator, definitely RPN. It's convenient for back-of-an-envelope calculations and use in meetings, which is what I want a calculator for. Keystroke programmability to automate some repetitive calculations is all I need, and GTO/GSB/ISZ/DSE will get the job done.

If the problem is complex enough to require RPL, with its highly regular but awkward syntax, I'd prefer to sit at a computer and work with GNU Octave or R or Matlab or Mathematica.


--- Les






I agree!


Good question! I like RPN for simplicity, RPL for the extended set of commands. Truthfully, I'm not sure if I can be on team-RPN or team-RPL yet because I like both.

Here's how I would imagine some of the RPL commands on an RPN (keystroke) machine:

FOR Loop:

FOR register#
** commands **


WHILE Test# (i.e. #1: x=y; #2: x>y; #3: x<y, etc)
** commands **

DO Loop:

** commands **
UNTIL Test# (i.e. #1: x=y, #2: x>y, #3: x<y, etc)

If text is allowed - it would be handled like the 41C/42S (?):

CHOOSE - each option is presented for 2 seconds. ("1. Choice 1", "2. Choice 2", "3. Choice 3"...) - and cycles until something is chosen. Up to 9 options.

"text 1"
"text 2"
"text n"

PROMPT - message displays for 2 seconds and then stops for input.


DISP n - message displays for n seconds.

"text" or register#

If graphing functions is featured:

PLOT - plots an equation as an algebraic object.


XRNG and YRNG would work the same way as it would on the graphing calculators.

Edited: 21 Oct 2011, 12:22 a.m.


Even yet another vote for RPN.

Although I do enjoy messing around with RPL from time to time, for what I use calculators for, RPN is the bee's knees.


RPL definitely.


42S+27S - RPN w/ full blown equation editor, i.e. a tuned Binford 9100 turbo (or, a 32SIII).


RPL for me, any day.
I (have to) use RPN often but I just don't like the ENTER behavior and the limited stack, the 48/50 way is so much easier for me. But I like the RPN's STO.



RPN please!!


Because I started with my dad's HP-35 (while in junior high school!), RPN is ingrained and natural to me. Most of the programs I still use today for civil engineering, I wrote on an HP-41CX and an HP-42S back in the 1980s and 1990s. I still program, but not nearly as much.

I have an HP-48G+ and I have dabbled with PRL programming. There is no question that it is enormously more powerful than RPN, but it's just not natural to me and I find it frustrating. It's also a pain to edit on the machine itself. Thank goodness for HPUserEdit. In the final analysis, I greatly prefer RPN.

However, I've had this question for years: when the 48 series was designed, why didn't HP include an RPN mode? It would have provided an excellent upgrade path for HP-41 and HP-42S users. I know some engineers who still use an HP-41 because they don't like the HP-48/-49/-50 series. I still use an HP-42S as my primary machine, though I also keep my HP-48G+ in my briefcase ready for use when needed.


Love RPN & still have 2 HP41s (CV & CX) BUT at the end of the day I've come to realize that RPL is my preference as well. My favourite calculators now are the HP 48GX & HP 50G.

Hope this helps.



Possibly Related Threads…
Thread Author Replies Views Last Post
  Writing RPL programs on OS X Sean Freeman 18 5,239 11-30-2013, 03:59 PM
Last Post: Sean Freeman
  48G vs 49G+ User RPL Speed Comparison John Colvin 7 2,607 11-16-2013, 10:07 PM
Last Post: Han
  RPL 32 David Hayden 4 2,083 11-11-2013, 11:34 AM
Last Post: David Hayden
  [PRIME] RPN: another attempt at returning more than one value to the RPN stack Marcus von Cube, Germany 5 2,466 11-05-2013, 02:44 AM
Last Post: Marcus von Cube, Germany
  HHC / HP Museum Programming Contest for RPN and RPL machines Gene Wright 18 5,608 09-22-2013, 09:39 AM
Last Post: Miguel Toro
  RPL long vs. short names peacecalc 5 2,038 10-30-2012, 01:25 PM
Last Post: peacecalc
  Mini-challenge: HHC2012 RPL programming contest with larger input David Hayden 14 3,622 10-05-2012, 10:36 PM
Last Post: David Hayden
  HHC 2012 RPL Programming Contest Gene Wright 33 7,817 09-27-2012, 01:57 AM
Last Post: Werner
  HHC 2012 programming contests coming soon (RPN and RPL) Gene Wright 9 2,699 09-21-2012, 03:38 PM
Last Post: Paul Dale
  RPL prog for Fibonacci on HP 48G needs minor modification. help. wildpig 68 16,633 07-09-2012, 09:38 AM
Last Post: Gilles Carpentier

Forum Jump: