Free42: Unlimited-length strings and other type extensions

[Thomas Okken]

While working on the big stack logic in Free42, it occurred to me that it would be nice to add a few new types to the type system. What got me thinking along those lines are lists, which would be very useful for creating temporary backups of the entire stack, but another HP-42S type system limitation that would be useful to tackle are strings. Unlimited-length strings would be useful for storing algebraic equations, and of course it would be nice to be able to use indirect alpha addressing without the six-character limit getting in the way of addressing seven-character labels and variables.

Real scalars with attached units will also require an extension to the type system...

Regarding the unlimited-length strings, it seems like this could actually be done almost transparently, since the current six-character limit is only enforced by ASTO. That means that all that would be needed is an ASTO variant that stores the entire alpha register. There would have to be some changes behind the scenes to allow unlimited-length strings to be stored in matrices (and thus also in numbered registers), but as long as the behavior of the regular ASTO doesn't change, this shouldn't affect legacy code at all.

Thoughts?

[Werner]

There's also the 44-character limit of the Alpha register itself? How would you create unlimited-length strings?
Werner

[Thomas Okken]

(01-24-2021 05:02 PM)Werner Wrote:  How would you create unlimited-length strings?

A couple of possibilities come to mind: an unlimited-alpha mode, or string concatenation on the stack... I hadn't really given that any thought yet, the immediate concern is whether allowing unlimited-length strings, as opposed to introducing a new unlimited-length string type alongside the 41C/42S-style 6-character strings, is a reasonable idea.

After that, many possibilities suggest themselves. With a more powerful text capability comes the desire for things like substrings, regex find/replace, and God knows what else... And of course a text editor, which will be needed anyway to support equation entry.

[Werner]

It is perhaps time for a 42S compatibility flag ;-)
Werner

[Thomas Okken]

How so? Nothing I'm proposing would break HP-42S compatibility. That's kind of a central theme with Free42.

[Werner]

I mean, instead of:
Unlimited stack mode
Unlimited alpha mode
Etc
Just one mode: 42S or not
Werner

[Thomas Okken]

It won't be that easy. I want the four-level-stack and big-stack modes to be able to coexist so that functions written for one mode can call functions written for the other and vice versa. The user will be able to tell at a glance which mode is active, because the X register will be labeled X: or 1: depending on that mode. But if big-alpha changes along with that, things will get messy.

[Guenter Schink]

Just a thought on ALPHA capabilities. Wouldn't it be nice to have a separate storage structure for strings? Addressable perhaps through pointers within ordinary memory. Exchangeable with the traditional ALPHA register. Recall store and exchange come to mind. Examples

ARCLI x
ARCLI IND 01

ASTOI x
ASTOI 00

AEXCI IND y

This would perhaps also accommodate databases to be build with the aid of matrices.

Günter

[mfleming]

(01-24-2021 09:25 PM)Guenter Schink Wrote:  Just a thought on ALPHA capabilities. Wouldn't it be nice to have a separate storage structure for strings? Addressable perhaps through pointers within ordinary memory. Exchangeable with the traditional ALPHA register. Recall store and exchange come to mind. Examples

ARCLI x
ARCLI IND 01

ASTOI x
ASTOI 00

AEXCI IND y

This would perhaps also accommodate databases to be build with the aid of matrices.

Günter

Sounds like a proposal to incorporate the HP-41 X-Memory/X-Function module(s) with all the file capabilities and commands. It would also increase the range of 41 programs that can be ported over. Put that in a DM42II and I'd be tempted to buy it.

[Paul Dale]

Thomas, all this sounds worthwhile. A list type would be useful. Operators working on strings would be great. Personally, I'd skip regex and head straight to a PEG grammar.

I do wonder if Free42 is becoming more RPL like over time. When thinking about extending the WP 34S, I started to understand the decisions behind the 28 series. The more I dug into it, the more RPL looked like the most natural successor to RPN.

I know others will disagree.


Pauli

[Thomas Okken]

(01-25-2021 03:24 AM)Paul Dale Wrote:  I do wonder if Free42 is becoming more RPL like over time. When thinking about extending the WP 34S, I started to understand the decisions behind the 28 series. The more I dug into it, the more RPL looked like the most natural successor to RPN.

I agree about RPL being the natural successor to RPN. Thinking about Free42 internals has made me come to understand and appreciate the logic behind the RPL design a lot more.

However, I don't want to create an RPL clone. I do still find keystroke programming easier, probably because it's just a better fit for the limitations of a small screen and keyboard. When editing RPL, the calculator always feels cramped and I find myself wishing for a QWERTY keyboard and a screen that can display way more text. And the absence of goto, break, and continue is annoying.

So I'm coming at is from the opposite direction: what can I add to Free42 to make it more capable, while maintaining the HP-42S look and feel? The big RTN stack and local variables address the inability to write recursive functions or create complex programs without littering the catalogs with variables, and SST→ and SST↑ were necessary because debugging long programs was just too painful without them. And FUNC helps create easily reusable functions.

With the things I'm working on now, my motivation is a bit different, since those are mostly features that I have often been asked to implement, not features that I myself have a need for... but once I started thinking about how to implement them, once again I found myself thinking of RPL, because lists suddenly appear to be very useful. I'm also reminded of the HP-42S design, in that some RPL features can be useful for implementing things behind the scenes, without necessarily making them available in user code.

Before I go crazy adding new functions, I am going to have to think about how to extend the raw file format, because the gaps left in the HP-42S opcode space are starting to fill up. Plenty of XROMs, of course, but functions with parameters are trickier...

[SammysHP]

(01-25-2021 10:32 AM)Thomas Okken Wrote:  So I'm coming at is from the opposite direction: what can I add to Free42 to make it more capable, while maintaining the HP-42S look and feel? The big RTN stack and local variables address the inability to write recursive functions or create complex programs without littering the catalogs with variables

Slightly off-topic, but how do you plan to implement stack operations like DROP or ROLL with the unlimited stack mode?

[John Keith]

(01-25-2021 10:32 AM)Thomas Okken Wrote:  

(01-25-2021 03:24 AM)Paul Dale Wrote:  I do wonder if Free42 is becoming more RPL like over time. When thinking about extending the WP 34S, I started to understand the decisions behind the 28 series. The more I dug into it, the more RPL looked like the most natural successor to RPN.

I agree about RPL being the natural successor to RPN. Thinking about Free42 internals has made me come to understand and appreciate the logic behind the RPL design a lot more.

However, I don't want to create an RPL clone. I do still find keystroke programming easier, probably because it's just a better fit for the limitations of a small screen and keyboard. When editing RPL, the calculator always feels cramped and I find myself wishing for a QWERTY keyboard and a screen that can display way more text. And the absence of goto, break, and continue is annoying.

Always nice to see more appreciation of RPL.

While a bigger display and keyboard are often wished for, I think that the power and flexibility of RPL more than makes up for the keyboard/display issues. RPL is almost certainly better than any other high level language for calculators in this regard.

I highly agree regarding BREAK and CONTINUE- I always find myself needing to fake them with kludgy FOR loops. OTOH I can't imagine a use for GOTO in a language like RPL.

Overall it is nice to see extensions and improvements to Free42 as long as they don't break compatibility with HP-42s programs. I am glad that you continue to see compatibility as important. However, we mostly use Free42 on our phones and PC's where EMU48 is also available. Therefor I'm not sure that extending Free42 in the direction of RPL is really needed.

[Gene]

More OT:

<rant>
I would glady use the RPN 28x CALC app for iOS for RPL on the iPhone with only ONE addition to the app ... a USER key.

To me that's fatal. If I write a procedure and store it, I want to be able to push a key and execute it. If I store something in a variable, I want to find it by pressing USER. The app does not have a key that brings up the soft menu showing user stored objects.

Sigh. Without that, it is interactive only and not nearly as useful as it could be.
<rant off>

Back to our regularly scheduled RPN programming.
Gene

[Peet]

(01-25-2021 03:24 AM)Paul Dale Wrote:  The more I dug into it, the more RPL looked like the most natural successor to RPN.
I know others will disagree.

You're right, I disagree across the board.

I see RPL as a fork, not a successor to RPN. I liked my HP-28S and I do like my HP-48G, but not a successor or replacement for my 11C or 41CV.
For a typical (scientific or business) pocket calculator I consider RPN to be the clearly better input option than RPL. It is clearer, more direct and less prone to errors and mistakes. Also for keystroke-programming RPL would be a kind of users hell but for a calculator with a structured programming I think RPL is amazing (as input and program-language).

I like being able to have entire programs and matrix or lists in the stack with the 28 or 48, but with the 41 this would probably do more harm than good and contradicts the concept of the 41.

P.S. A successor usually replaces the predecessor, HP still builds RPN calulators but where is RPL? In that way RPL would be more like a wrong step in evolution than "natural successor".

[Thomas Okken]

(01-25-2021 02:20 PM)SammysHP Wrote:  how do you plan to implement stack operations like DROP or ROLL with the unlimited stack mode?

Why, in C++, of course

But seriously:

R↓ and R↑: roll the entire stack
DEPTH, DUP, DROP: like in RPL
DUPN n, DROPN n: like DUPN and DROPN in RPL, but with postfix parameters
PICK n and UNPICK n: like PICK and UNPICK in RPL, but with postfix parameters
R↓N n and R↑N n: like ROLLD and ROLL in RPL, but with postfix parameters

[Dave Britten]

Before you go too deep down the rabbit hole building unlimited-length strings, might I suggest stealing a design from the TI-95 Procalc? It uses an alpha register very similar to the 41C and 42S, but the alpha store and recall operations differ in that they save and recall the whole alpha register into a block of registers (10 I think?) starting at the one you've specified. Thus the TI-95 equivalent of ASTO 00 stores alpha across registers 00-09 if I'm remembering all the details correctly. So maybe just add ASTOM and ARCLM (the M standing for Multi) which do the same, using whatever number of registers are needed to hold the entirety of the alpha register, or if a variable name or stack register is supplied instead of a register number, store it as a one-column matrix with the required number of elements. ARCLM would of course need a bit of argument checking to make sure it's a valid alpha matrix.

[Werner]

XTOA already does that (the ARCLM part I mean)
Werner

[Claudio L.]

(01-25-2021 10:32 AM)Thomas Okken Wrote:  However, I don't want to create an RPL clone.

That's a relief!
You would've made newRPL look like a kid's toy... maybe I deserve it, since I added a 4-level stack to newRPL first!

[Thomas Okken]

(01-26-2021 08:57 PM)Claudio L. Wrote:  

(01-25-2021 10:32 AM)Thomas Okken Wrote:  However, I don't want to create an RPL clone.

That's a relief!
You would've made newRPL look like a kid's toy... maybe I deserve it, since I added a 4-level stack to newRPL first!

I doubt that, but thank you!