Jump to content


Check out our Community Blogs





- - - - -

Reverse Polish Lisp: A charming misfit of a language

Posted by gregwarner, 05 April 2011 · 3502 views

I had the pleasure of receiving my first graphing calculator when I was in 9th grade geometry. In a world of TI-83's, I was the lone ranger armed with an HP 48G. My father gave it to me, and I absolutely loved it. I loved it because it operated in Reverse Polish Notation, and with my dad using HP's being an engineer, the acorn did not fall far from the tree. I was quickly typing long equations with ease, correctly applying the order of operations in my head without typing a single pair of parentheses. I had given a nickname to the mental task of keeping track of the operators as I keyed in the equations. I called it "mental juggling." It wouldn't be until college that I learned the actual name for this method was a binary parse tree.

The biggest reason why I loved this calculator was that, while everyone else was programming their calculators in TI-BASIC, I was programming mine in a purely functional language. (Again, it wouldn't be until college that I would learn the term, "functional paradigm.") The HP calculator was programmed in a language known as System RPL, which stands for "Reverse Polish Lisp," and a subset of that language, known as User RPL, was exposed to the user for writing programs. Having no prior experience with any language other than BASIC, I was forced out of my element into a stateless language with no GOTO's. I had figuratively been tossed into the deep end without my floaties. It was time to learn real programming.

That summer, I mowed lawns till sweat was pouring down my face in order to save up enough to buy the next model of HP: the 49G. With 2.5 MB of memory onboard, I could finally spread my wings and soar. I wrote dozens of programs, including a little Mortal Kombat klone. (Note the use of the letter "k" in keeping with Mortal Kombat tradition.) This was my beloved calculator, and my beloved language. It was the language that taught me proper programming style; the language which introduced me to the field of Computer Science.

I purchased several more upgrades to that calculator since, but my enthusiasm for the language trailed off as I entered college. I fell in and out of love with new languages, first C++, then PHP, followed by MySQL, C#, and more recently, Java. But, like you never forget your first high school love, I've never forgotten my first language.

Recently, my love for the language was rejuvenated by my discovery of GNU RPL/2, a PC port of the language. I've played around with it, even modified the source a little to better suite my tastes. The language is oddly charming, despite its shortcomings.

RPL is the forbidden love child between Forth and Lisp. It utilizes the runtime stack from Forth, while retaining many of the list processing features of Lisp. Indeed, RPL treats programs as lists of instructions, and all list operations can be performed on programs and functions.

RPL is dynamically typed, a feature I used to rely on heavily before I was introduced to statically typed languages. Now days, I scoff at dynamically typed languages, arguing that it's more difficult to prove the correctness of a program when you can't know the types. Simply relying on runtime errors is no excuse for not being able to prove an algorithm at compile time. Yet this elitist attitude is stayed as I am reminded that RPL never had static types.

RPL was also notoriously difficult to prove the correctness of your program. So many operations required a certain number of operands to be already on the stack, throwing a runtime error if either the type or the number of operands was wrong. Take for instance this function which increments a value by one and pushes it back onto the stack:
<< 1 + >>
When the interpreter hit the "+" operand, it would try to pop 2 objects. Should the programmer make a mistake and call this function before pushing a variable first, or if he had pushed a non-compatible type, he would have to rely on extra runtime handling to account for all his mistakes. The compiler had no way of checking your program to be certain of these things. Perhaps that was a shortcoming of the language, or perhaps, it forced me to be more careful of a programmer.

Despite these problems with the language, it retains its allure with me, if not only for some completely irrational reason. Every conviction of my programmer's faith is violated in RPL, yet I still enjoy coding in it. I get a thrill every time I write RPL when I find myself going back and performing complex "mental juggling" operations in my head to ensure a function's correctness before I commit. It's nostalgic, exciting, and challenging. Perhaps that's why I still love it so much. Even so, I could never see myself coding anything so complex as a database application with it. (Although GNU RPL/2 does have a MySQL library.)

It was a good language. Even on the calculator, it had many excellent features that weren't available in TI-BASIC such as exception handling, garbage collection, and even direct access to the OS API's. I'll never forget it, and, perhaps, one day I'll pick up GNU RPL/2 again, if not only to relive the golden days of my youth.

Note: if you want to download GNU RPL/2, here's the link: http://www.rpl2.net/

  • 0



I still love my HP49G. It's my primary calculator when not teaching math. TI83 and TI89 are nice, but don't compare. I wrote functions to do pivots for linear programming on my old HP48GX, a process that involves completely disassembling a matrix, manipulating it, and reassembling it.

I'm glad someone else enjoys it, too.
    • 0
Recommended from our users: Dynamic Network Monitoring from WhatsUp Gold from IPSwitch. Free Download