So.. any improvements RPN-wise ???

[Wes Loewer]

(04-01-2019 08:02 PM)Didier Lachieze Wrote:  1) UNDO: Shift Ans will recall to the stack the last function arguments

Yes, I use that frequently. Not quite the same as UNDO, but pretty close.

(04-01-2019 08:02 PM)Didier Lachieze Wrote:  2) The ability to interactively expand a list (like EVAL or LIST->)
The following program assigned to a user key (here Shift 9) will do it for the list on the stack level 1. You'll need to press Enter.

Say, that's pretty slick! I think I'll assign it to the EVAL (Shift Comma) key since that's how I usually expanded lists on the50g.

Forgot to include another goodie.

7) CMD key to recall command history

Actually, I assgined to that key a program from John H. Meyers of comp.sys.hp48 fame that gave an unlimited CMD history. I frequently made use of that.

[Wes Loewer]

(04-02-2019 04:37 AM)Wes Loewer Wrote:  

(04-01-2019 08:02 PM)Didier Lachieze Wrote:  1) UNDO: Shift Ans will recall to the stack the last function arguments

Yes, I use that frequently. Not quite the same as UNDO, but pretty close.

Also, unlike UNDO, Shift-Ans won't help you if you accidentally delete something from the stack, either by hitting Del too many times, or by going in to the History and deleting the wrong value.

On the 50g, even DROP and SWAP store the affected values in Ans. I'm not sure I like that behavior, but if the Prime did this, then you could use Ans to at least retrieve an accidental DROP.

[Wes Loewer]

(03-22-2019 09:25 AM)Tim Wessman Wrote:  RPN does not suck. You just can't program in RPN/RPL.

While it was highly satisfying to come up with a really compact RPL program (like Joe Horn's parallel resistors program \<< * LASTARG + / \>> ), using PPL is definitely better for longer programs. When I look back at some of my old RPL code, I have to step through them to remember what in the world I was doing. It's not unlike when I look back through my old ASM code.

One thing in my pipe dream wish list would be the ability to access and modify the RPN stack from within a PPL program. That would make RPN much more robust.

[TravisE]

(04-03-2019 06:21 PM)Wes Loewer Wrote:  While it was highly satisfying to come up with a really compact RPL program (like Joe Horn's parallel resistors program \<< * LASTARG + / \>> ), using PPL is definitely better for longer programs. When I look back at some of my old RPL code, I have to step through them to remember what in the world I was doing. It's not unlike when I look back through my old ASM code.

I've had some of that problem with RPL myself, especially since it did not natively support comments (unless you kept a separate source file in a string, but then that made the development process more clunky and convoluted). You had to be especially careful to break up programs and use good names, and even then it could be confusing. But it was fun (and most of all, convenient) to write and use them.

Languages like PPL are certainly more readable typically, though PPL in particular is a bit formal for my taste. Requirements such as explicit variable declaration and finicky syntax elements like semicolons after every single construct are rather annoying when trying to throw together an ad-hoc program, especially on a handheld device with the limited type of keyboard the Prime has.

[toml_12953]

(04-03-2019 07:34 PM)TravisE Wrote:  Requirements such as explicit variable declaration

You don't have to pre-declare many variables in PPL. The global variables A-Z and any other globals are open. You can use them without declaring them. Lists and arrays can be used as well with no declaration if you use the predefined names. If you want to use your own names, you can declare them as LOCAL.

[Wes Loewer]

(04-01-2019 05:59 PM)Wes Loewer Wrote:  I agree. It's not that bad, but there are some things that I really do miss.
...
5) KEEP (opposite of DROPN)

I happen to notice that STRINGFROMID contains the string "RpnKEEP". It certainly leads one to wonder if there is a KEEP command that is hidden, or maybe planned but not implemented. For RPN with an almost endless stack, it seems a bit strange that KEEP is missing. In fact, I wish there was something similar for the non-RPN history.