The 24 of July, Tim Wessman was kind enough to ask us, HP calcs users, what could be RPN on something like a HP39gII , how would we like it done? What would be "absolutely critical"? What would be nice but not critical?

Here is (in my bad english) an attempt to summarize our discussion. Sorry for mistakes, errors or forgetting things...

« RPN HP39gII » : An attempt to summarize our discusion

--------------------------------------------------------

1/ We want RPN !

Not surprisingly, all contributors think that RPN on a device like the HP39gII would be wonderfull. However for Patrice, it is first critical to fix operator prority on the present HP39gII ( modulo command).

2/ About the stack

Most persons who spoke on the subject prefer an infinite stack. Christian would prefer something like a 50G stack (infinite stack, and SPC or ENTER as separators, and no DUP on ENTER ). However Bill Wiese think the perfect programmable calculating device has bone-stock HP RPN with big ENTER key, XYZT+L registers, Z copy down etc.

No general idea emerges about what could be the stack manipulation commands (Nota : but it is an important topic, an infinite stack could not be manage as a finite stack – we must disuss this.

Gilles wrote that the "forth legacy" is fine for him, but perhaps more mnemotechnics commands could be interesting
(Nota : nobody wrote about the necessity of an interactive stack manipulation. But of course it is needed (cf HP50G Upper arrow)

3/ RPN vs RPL

As usual, 'classic RPN' vs 'RPL RPN' was in debate. Some find RPL too complex (Pal G ...), others find it simple to use and very powerfull (Oliver ...) Others (Wes Loewer...) find 'classic RPN' very hard to follow compared with RPL more easy to read. But Even those who like RPL wrote that there are some problems :
The lack of BREAK / CONTINUE
The use of LOCAL variables too heavy and unintiutive

For Eddy RPL and RPN are basically the same structure. Instead of commands like x>y?, LBL, GTO, R/S, and ISG in RPN, we have commands FOR-NEXT, WHILE-END, PROMPT, WAIT, and PAUSE in RPL. Both use objects in the stack and manipulate them to obtain desired results. Both are more challenging to read than say, a program written in BASIC.

4/ Programming vs interactive usage

RPN yes ! At least for interactive usage. But what about programming ?

Some people (Jim Horn, Christian …) wrote interactive use and programming aspect are quite different situations. So we could have RPN for interactive usage, and 'classic' 39gII language (no RPN entry) for programming. Gilles thinks it's not a good idea at all to have such a difference between the 2 modes (the power of a 50G/RPL is here !).

5/ About programming

X34 and other people think there is no need to have RPL, since what X34 called « Modula-39 » ;) is much more structured, orthogonal, simpler and more powerfull one. Gilles and Oliver wrote that you can do many things in RPL in a more easy way than in the 39gII embedded language.

All noted that the 39gII language is very readable and clear...Some wrote it must be improved (for example the lack of MAP command, retrieve the TYPE of a variable, List processing …)

Several people wrote that it's not a problem to have several languages on such a calc (like on the 50g)

Four ideas emerged about programming  :

a/ RPN OK, but for interactive use only and keep the 39gII langage as it is. No need of RPN/RPL language

b/ RPL legacy. RPL is a powerfull and perfect language for a calc. Keep it ! Improve it !

c/ Classic RPN legacy. RPN 'classic' is a perfect tool for a Calc. We want it !

d/ HP39gII language is interesting and could be adapted to a Reverse polish notation with small efforts

Hummm... Do with this Tim ;)

6/ An alternative way : RPN and algebraic, Both for the same price !

Bill Wiese wrote that functions could run in postfix calc mode or prefix-with-arguments mode in BASIC.

Oliver (who create RPL+) show us we can mix in a smart way RPN/RPL and algebraics. Gilles also think so. The idea is to have a calc wich works _in the same time_ both in RPN and algebraic

IF sum>(n^2/log(10)) THEN … (no space => algebraic object)

or

IF sum n SQ 10 LOG / > THEN

The space (or no space) separator could be a key to differentiate RPN and Agebraic expression

So we could do :

45 SIN A *

SIN(45) A *

SIN(45)*A

'SIN(X)' 'LOG(3*X)' * give 'SIN(X)*LOG(3*X)'

P1 P2 P3 Myfunction

MyFunction(P1,P2,P3)

A:=n^2/log(10) store in 'A'

n^2*log(10) just put the result value on the stack

=> A (or => 'A', or 'A' STO if we want RPL legacy) store in 'A'

n SQ 10 LOG * put each value on the stack applie functions and calulate

n² LOG(10) * will work also

Another way would be to use ' or ` to diffenciate RPN and algebraic part. (immediate and delayed evaluation).

Edited: 26 July 2012, 6:21 a.m. after one or more responses were posted

Hello,



FYI:

This goal could be accomplished quite easy.



Simply go back to the 48GX O.S. and port it to another processor architecture.

This O.S. has been proven to be very stable and reliable.



Most of the O.S. are written in SYS-RPL (>75% if memory serves me well).

For advanced stuff that a new processor would offer simply add some “hooks” so

that you can control it from the outside.



The 48GX O.S. relies on three 5 nibble registers, two data pointers and a program

counter. Additionally a HW return stack is used, that is also 5 nibbles wide and from

two internal registers also 5 nibble are used.

The data that is hold there is also used in the reserved system RAM for operating the

machine.



So at a total minimum these code areas would need adjustment for a larger base,

resulting in a new compiler.

It would not be too hard to do this, I believe with some skilled people this could be

done in less than a year and there you have a modernized, proven O.S. that could

also work/communicate with the “outer” world.



Then add the more advanced stuff from the MetaKernel you want and add the CAS

(the CAS is written entirely in SYS-RPL, btw). OTH, if you do want the “old” CAS use

another one as for a “modern” processor usually a C compiler exists.



The beauty and advantages of such a scenario would be

- reuse of proven code

- backward compatibility at source level for existing code

(same way as it was done with 48 to 49 code)

- protecting customer investment into the machine (time and money)

- reuse of existing documentation

- USP compared to other calculator manufacturers

- much more

Alternatively simply update the 50g with some more memory and a larger screen to

bridge over the time until such a machine is ready.

Updating the 50g would *not* be so hard (and would not take that long, as is said

already in the past), although this is denied/contested again and again, but that does

not make it truer.



And I know what I am talking about, as I have written much more software for the 50g

(and by that I mean real low level stuff) than what HP has released for it...



Regards,

Andreas

http://www.software49g.gmxhome.de

Edited: 26 July 2012, 6:16 a.m.

Hi Andreas,

Quote:

---

Alternatively simply update the 50g with some more memory and a larger screen to bridge over the time until such a machine is ready.

---

Give me this, easier local variables definition in RPL and some BREAK and CONTINUE command and I will be an happy man ;D

RPL is also a perfect system for CAS use ... And the 50G CAS is very interesting even if there is no more evolution since years.

On the details of your message, I can say nothing because if I use a lot RPL I know quite nothing (nor I want to know) about "how it works", neither about SYS-RPL. But as far as I know, your message seems makes sense.

Quote:

---

c/ Classic RPN legacy. RPN 'classic' is a perfect tool for a Calc. We want it !

---

Quote:

---

Footnote:
Does this mean the end of RPN or an RPN like calculating structure? With the modern "textbook" type entry systems it's all a bit of a moot point anyway. Why struggle with intermediate results on a stack (RPN) or counting parentheses (ALG), when you can see the whole formula and easily review it for correctness?

---

Hi

When I work with RPL, I use a lot algebraic formula. I use the marvelous equation writer to create or edit them. Then they are on the stack or in variable. But I need an easy way to work with them. And RPN (I mean reverse polish notation) is the simplier way I know

Suppose you have on the stack something like
'3*Y+SIN(X)/e^X'

and another part (calculating elsewhere) with
'1/Y'

You want the 2 parts to be equal. Just push the = key and you get :

3*Y+SIN(X)/e^X=1/Y'

Now you want to solve for 'Y' function of X

'Y' SOLVE

give (in more beautiful presentionthan here) :

{
'Y=-((SIN(X)+sqrt(12*EXP(X)^2+SIN(X)^2))/(6*EXP(X)))' 'Y=(-SIN(X)+sqrt(12*EXP(X)^2+SIN(X)^2))/(6*EXP(X))'
}

You want only the second

2 GET (or EVAL NIP, or EVAL SWAP DROP with 3 key pressed)

'Y=(-SIN(X)+sqrt(12*EXP(X)^2+SIN(X)^2))/(6*EXP(X))'
etc.

There is a future for RPN : It is to eat algebraic and manipulate it.

Edited: 26 July 2012, 8:48 a.m.

Bart, I agree with one of your footnote points, but disagree with the other.

1) Equation writer is very slick when typing a large equation. I agree too many parenthesis can lead to typos and errors, and can obfuscate an otherwise easy to read equation. Unfortunately, I don't think the 39GII has an equation writer.

2) Dealing with intermediate results on a stack is not a struggle, it is desired. I want intermediate results. It is the primary reason I learned RPN. ALG mode insists you enter the entire equation, then reveals the answer or complains with an error message if your parentheses are wrong.

Edited: 26 July 2012, 5:17 p.m.

Quote:

---

easier local variables definition in RPL

---

How is local variable definition hard? How would you make it easier?

Quote:

---

and some BREAK and CONTINUE command

---

At first I thought you were asking for what RPL provides as HALT, but maybe you mean the equivalent of break and continue in C?

- How is local variable definition hard? How would you make it easier?

Suppose you need a 3 local variables in RPL, but you don't kwow in the beginning of a 'bloc' what are their values

You can do something like :

<< 0 0 0 -> a b c  @ initialise with a garbage value

 <<

   My prog

 >>

>>

or

<<

  First part

  Here i know the first value of a

  -> a

  <<

   Second part

   Here I can itialize b

   -> b

    <<

      etc.

    >>

  >>

>>

and if you 10 local variables,
0 0 0 0 0 0 0 0 0 -> a b c e f g h i j

is not very beautiful

Is it not more logic and easier with ythis alternative :

<<

  { 'a' 'b' 'c' } LOCAL

  My prog

>>

BREAK is to exit a loop structure (FOR / REPEAT / DO ...)

 1 100 FOR n

   ...

   IF test THEN BREAK END

 NEXT

CONTINUE to jump to the start of the next iteration

You can do without, but in some case it is very usefull

Edited: 26 July 2012, 1:43 p.m.

Without making really big changes to the implementation of RPL, I think you'll still need a set of guillemets around the scope of the local variables, since it needs to be a block:

<<

  { 'a' 'b' 'c' } LOCAL

  <<

    My prog

  >>

>>

I have only rarely found the need to have local variables without a needed initial value, and when I have needed them, I've rarely needed more than two, so I don't think I'd personally find this feature to be of much use. And I think I can type

0 0 0 -> a b c

faster than I can type

{ 'a' 'b' 'c' } LOCAL

anyhow.

On the other hand, I agree that CONTINUE and BREAK would be very useful.

In fact here is already a LOCAL command in the 50G : see AUR page 3-137

LOCAL

Type: Command

Description: Creates one or more local variables. This command is intended mainly for use in Algebraic mode;

it can not be single stepped when a program containing it is being debugged in Algebraic mode.

Access: Catalog, …μ

Input: Level 1/Argument 1: A list of one or more local variable names (names beginning with the local

variable identifier ←), each one followed by an equals sign and the value to be stored in it. Any

variable not followed by an equal sign and a value is set equal to zero.

Output: Level 1/Item 1: The input list.

Flags: Exact mode must be set (flag –105 clear).

Example: Create local variables ←A and ←B and store the values 0 in the first and 2 in the second.

Command: LOCAL({<-A,<-B=2})

Result: {<-A,<-B=2}

I tried to use it in RPL (seems not forbidden), but without success.
PS : But I realise i don't tried with the <-

Edited: 26 July 2012, 5:59 p.m.

Quote:

---

How is local variable definition hard? How would you make it easier?

---

To define, assign, and re-assign a local in RPL, you have to do:

<< -> n <<

   ...

   6 'n' STO

   >>

>>

<< =n

   ...

   6 =n

>>

- using "=" to do assignment assignment and re-assignment; like most any language

- no block ("defining procedure") is being created

- same syntax for assignment and re-assignment

- the "=" is fused to the variable name to disambiguate from the normal use of the "=" operator

Keeping in mind immediate algebraics which work by having no spaces in an expression, finally, another way emerges:

<< =n

   ...

   n=6

>>

There should be no need to declare a local. Just assign whenever you need it. If you use a never assigned local name it becomes a "name" in RPL, as always.

<< =x

   IF x<10 THEN y=7 END

   y

>>

Another thing that locals should do, is have "block scope", where code fragments (declared with << >> or { }) are our blocks. That is, they should be usable from within such code fragments. This is another expectation from most languages and also permits things like recursive anonymous functions.

The proposed changes are pretty easy and I can report from using local vars like this in RPL+, that I've never looked back. (Though RPL+, being strictly a superset of RPL, allows you to work the old way, too, and even mix and match old and new.)

EDIT:

Once you have the syntax above, the next step is to replace STO+, STO/, etc. with

   x+=5

   x/=5

RPL+ does allow

   5 =+x

   5 =/x

Also, it permits array access, read and write, like so

   x[3]

   7 =x[3]

Combine that with immediate algebraics, and you have

   x[5+y*2]=log(f)*5

Even though this looks like "every other" language now, it's still RPL! Everything you know about RPL still works. It's just an option to also write things, and not alienate new users. (Not that I'm suggesting "RPN" users would embrace this style, of course...)

Edited: 27 July 2012, 4:27 a.m.

I like very very much the general idea...

In fact, RPL+ seemed mysterious to me before because I did not understand the importance of space character

To mix in such an easy way RPN (i mean reverse polish notation) and algebraic is very powerfull. You can have the best of the 2 worlds in the same time !

Just be carefull about distinguish the "=" for affectation and the mathematical equal "=" .

I dont like very much "=" for affectation, because A=A+1 is a non sense. I prefer the := of the 39gII for example, or => and <= . But its a detail.

Edited: 27 July 2012, 6:13 a.m.

I like RPL, but I think it can stand to be improved. There probably needs to be a source and executable file,so you can have formatting, comments, etc. If it had that, I don't think RPL would necessarily be that hard to read. Some other suggestions in this thread for an evolved RPL could be good.

> There probably needs to be a source and executable file,

> so you can have formatting, comments, etc.

That does already exist, even for USER-RPL.



@Eric

@Gilles

You can "break" out of everything using the error trapping mechanism

of USER-RPL.



Regards,

Andreas

http://www.software49g.gmxhome.de

Quote:

---

Suppose you need a 3 local variables in RPL, but you don't kwow in the beginning of a 'bloc' what are their values

You can do something like :

<< 0 0 0 -> a b c  @ initialise with a garbage value

 <<

   My prog

 >>

>>

or

<<

  First part

  Here i know the first value of a

  -> a

  <<

   Second part

   Here I can itialize b

   -> b

    <<

      etc.

    >>

  >>

>>

---

Edit:


Declare and inicialise at the beginnig, add a value anywhere, naturally.

Edited: 27 July 2012, 3:45 p.m.

Hi Crawl,

You don't need two separate files in order to have RPL preserve user formatting.

I think it's purely a historic accident (based on the then-valid rationale that every byte is precious) that explains that RPL on HP 28-50g was compiled into pointers when entered.

Representative of how it could be done elsewhere, ND1 does no such thing and simply compiles when the need for execution arises. If a RPL code fragment is used in a processing command like DOSUBS, filter, or such, it's compiled before use and then reused in compiled form in the internal loop. But the only thing the user ever sees is the user formatting-preserving text form.

If HP produces another RPL-capable machine, I'm sure they'll fix that in the same way. And, yes, agreed, automatic formatting didn't exactly help readability of RPL.

Edited: 27 July 2012, 5:21 p.m.

For "big" programs, i think the best is to write them on a PC, tests and then tranfer. So you can put comments in the PC file with @ and the formatting is preserved.

For UserPRL HPUserEdit is a prefect tools and works fine with EMU48 (just click TRANSFER)

See the following:

Corrections in calculations on a modern "textbook" display calclator

Put yourself in a young person's shoes looking for a calculator to take them through school, college or university - what is more attractive? A stack with intermediate answers but where each calculation has to be repeated, or where the answers are flowed down? You can easily do an impromptu what-if scenario without cursing for not having first set up a set of equations. There are actually intermediate results visible too that also get updated with a change in input on earlier equations.

You and I like RPN, but it's going to look a bit old fashioned to a younger generation. I would like to see an updated 50g-like calculator along the lines of the 39gII, but I would think RPN should be an option and take a back seat. As for programming language, the style that has been termed "RPN style" is not right for this kind of calculator - and RPL? well I like RPL and I like Pascal too, but both seem to have little support these days.

That may be well and good, but there's no reason a future iteration of RPL shouldn't have that built-in.

Yes, I know about using error trapping to break loops, but, come on, I think we have to admit that is an unintuitive solution to the problem.