3 ms·

Just in the last few days I've been playing around with my HP48 and wondering how close to a reverse scheme with no brackets RPL is. I figured the only real di

Just in the last few days I've been playing around with my HP48 and wondering how close to a reverse scheme with no brackets RPL is. I figured the only real difference is that scheme has list of lists, but you can't have a stack of stacks with RPL. Really cool.

mschaef 7y ago
It has the first class function objects, but not the lexical scoping. Try entering this and storing it into a variable: << -> x << << x >> >> >> If you run that object with something on the stack, you'll get this in return. 1: << x >> That x is a local variable reference, which makes it different than if you just entered this << x >> And if you evaluate it, it blows up with an error to that effect. (Since RPL doesn't really close over the lexical environment.) Years ago, I wrote a Scheme-based derivative of RPL that fixed some of this and found it rather fun to play around with.
- chewzerita 7y ago
  https://min-lang.org/learn-definitions/ https://min-lang.org/learn-definitions/ Min has lexical scoping too.
- vcbdcgdg 7y ago
  I have a question, if you don't mind: I have a stopwatch function in my HP48 that I don't want using a local variable (avoid polluting my precious menu), or having to keep it in a stack. Instead I want the value of the last time I ran the program to be stored within the program itself. I believe this is called a closure in CS. Right now I can have << value -> X 'expression' EVAL rest of the program >> And it'll work just fine, but how could I get the value at the very top modified? (I know my cell phone has a stopwatch. We're not allowed phones at work)
  - mschaef 7y ago
    > I have a question, if you don't mind: Not at all. > I have a stopwatch function in my HP48 that I don't want using a local variable (avoid polluting my precious menu), or having to keep it in a stack. The first thing that comes to mind is that there's a hidden directory at the root that the ROM itself uses to store stuff like this. This link talks a bit about how to get there: https://www.hpmuseum.org/forum/thread-12986.html https://www.hpmuseum.org/forum/thread-12986.html This uses SYSEVAL to call into a normally-not-visible object that puts the name of the directory on the stack. From there, you should be able to read/write the variable. You may also be able to do some hacky stuff with self-modifying code, but that's honestly something I'd avoid unless you want to try it for fun.
Throwaway_5438 7y ago
You can trivially change Scheme to RPL by simply putting the function name last, instead of first. Apart from that is would be the same. There doesn't have to be a stack either. If you mean concatenative languages (like Nim), then the difference is that a function in concatenative languages can push and pull an arbitrary number of arguments. This makes it trivial for a function to return two arguments, of which the next to functions use one each. It makes it non-trivial to have var-args. Magic like having a function consume as many further elements as the number on the top of the stack says is of course also possible. Edit: Oh sorry, I confused "RPL" with "RPN". I don't know about RPL.
- sansnomme 7y ago
  Somewhat relevant: SHUNTING-YARD
- mschaef 7y ago
  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.

mschaef 7y ago

It has the first class function objects, but not the lexical scoping. Try entering this and storing it into a variable: << -> x << << x >> >> >> If you run that object with something on the stack, you'll get this in return. 1: << x >> That x is a local variable reference, which makes it different than if you just entered this << x >> And if you evaluate it, it blows up with an error to that effect. (Since RPL doesn't really close over the lexical environment.) Years ago, I wrote a Scheme-based derivative of RPL that fixed some of this and found it rather fun to play around with.

chewzerita 7y ago
https://min-lang.org/learn-definitions/ https://min-lang.org/learn-definitions/ Min has lexical scoping too.
vcbdcgdg 7y ago
I have a question, if you don't mind: I have a stopwatch function in my HP48 that I don't want using a local variable (avoid polluting my precious menu), or having to keep it in a stack. Instead I want the value of the last time I ran the program to be stored within the program itself. I believe this is called a closure in CS. Right now I can have << value -> X 'expression' EVAL rest of the program >> And it'll work just fine, but how could I get the value at the very top modified? (I know my cell phone has a stopwatch. We're not allowed phones at work)
- mschaef 7y ago
  > I have a question, if you don't mind: Not at all. > I have a stopwatch function in my HP48 that I don't want using a local variable (avoid polluting my precious menu), or having to keep it in a stack. The first thing that comes to mind is that there's a hidden directory at the root that the ROM itself uses to store stuff like this. This link talks a bit about how to get there: https://www.hpmuseum.org/forum/thread-12986.html https://www.hpmuseum.org/forum/thread-12986.html This uses SYSEVAL to call into a normally-not-visible object that puts the name of the directory on the stack. From there, you should be able to read/write the variable. You may also be able to do some hacky stuff with self-modifying code, but that's honestly something I'd avoid unless you want to try it for fun.

Throwaway_5438 7y ago

You can trivially change Scheme to RPL by simply putting the function name last, instead of first. Apart from that is would be the same. There doesn't have to be a stack either. If you mean concatenative languages (like Nim), then the difference is that a function in concatenative languages can push and pull an arbitrary number of arguments. This makes it trivial for a function to return two arguments, of which the next to functions use one each. It makes it non-trivial to have var-args. Magic like having a function consume as many further elements as the number on the top of the stack says is of course also possible. Edit: Oh sorry, I confused "RPL" with "RPN". I don't know about RPL.

sansnomme 7y ago
Somewhat relevant: SHUNTING-YARD
mschaef 7y ago
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.