RPL is one of the more interesting later developments from HP's calculator group. After the HP41C series, they realized that continue the development they wante

RPL is one of the more interesting later developments from HP's calculator group. After the HP41C series, they realized that continue the development they wanted to do, they needed a higher level programming environment. To that point, my understanding was that it was all essentially machine/assembler level code written for their (fully custom) CPU architecture. Their response to this was RPL, which borrowed rather heavily from both FORTH and Lisp. In keeping with their RPN user model and the light memory footprint of FORTH, RPL used a threaded execution model composed of a hierarchy of function (procedure?) object definitions. As with FORTH, these could be either defined in machine code or defined in terms of other RPL words. From Lisp, RPL borrowed the notion of tagged data objects and first class function objects. A user program written in RPL was composed of one or more function objects bound to variables. Keeping with FORTH, user program objects were in many ways peers of the objects built into the system ROM. Same format, execution, etc. If you look at the documentation around these calculators, you'll see references to both "System RPL" and "User RPL". The real difference here is that when HP defined the words that were built into the calculator ROMs, only a fraction were given names within the ROM. These were the words that HP vetted for customer user and deemed safe (by ensuring they all checked types, etc.) "System RPL" words didn't necessarily have the same type checking and couldn't be used without risk of corrupting memory etc. Of course, they were also faster and had some additional capabilities if used with care. These are how HP built the ROMs internally, and with HP's help, the internet community developed tools for non-HP folks to write so called "System RPL" and even machine code level software. If you came at one of these RPL calculators from the perspective of one of the earlier traditional RPN calculators, this could all be unsettling. There were a number of various changes to the UI, starting with the fact that the stack was no longer bound at four levels. It's a definite change in perspective. From the perspective of a new user, the calculators had a great deal of internal consistency to their software model that could make them a lot of fun to use. It was in many ways 'turtles all the way down', which meant that even if you never used the system functions, you still could pretty easily write hook functions for the the REPL, custom menus and key bindings, and all with what would in these days be described as first class functions bound to event handlers. (On a 4-bit custom CPU that would run for weeks on three AAA batteries.) One final aspect I'll leave you with is that, while the flagship calculators were almost all still RPN, HP also used this platform internally for a number of other non-RPL models. Some of the business calculators, the HP38, etc. all used this software, even though they did not necessarily expose a stack through their UI.