newRPL: [UPDATED April 27-2017] Firmware for testing available for download

[Claudio L.]

(02-28-2017 08:46 PM)Han Wrote:  That would work perfectly fine for a routine that checks each individual combination (lots of unnecessary tests in a general case). It was fairly common in the HP48 series to break up the testing based on the shift planes (and then the actual key). I vaguely recall that many parameterized outer loops had key handlers that broke up the cases based on the shifts. Testing by shift planes reduces the number of tests in the general-case and worst-case scenarios. It also helps organize the key definitions (by shift planes) better than a simple list that may or may not be organized.

Whatever your choice, I still think a fixed format where every character (or every two) represents some bit of information. Then users can choose to a single CASE block, or break it up into shift planes by using the fact that the keycodes are in a fixed format. My recommendation for codes (slight alteration of yours):

"XYYZ"

X = KEY = A-Z, 0-9, *, -, +, ., u (up), d (down), l (left), r (right), b (backspace), e (enter), s (space), o (on) -- please note upper vs lower case
YY = SHIFT = two characters; first is shift combination, second is hold or not hold (a = alpha, l = left shift, L = alpha left shift, r = right shift, R = alpha right shift, H = hold)
Z = MODS = keep as you already described

On-hold would be: "o H "
Right shift B would be: "Br "
Alpha B would be: "Ba "
Right shift (hold) B would be: "BrH "
Alpha right shift B would be: "BR "
Alpha right shift (hold) B released would be: "BRHU"

You can even reduce YY into a single character if you opt to have A for alpha hold, and then use \( \alpha \) and \( \beta \) for alpha left hold and alpha right hold respectively, and use O for on-hold --> "oO "

Lastly, I don't recommend using "." for both the key and for the separation of the codes even though it is not possible to confuse the two.

This makes perfect sense if you want to break it up, to access characters in a fixed position you'd have to use SUB, and if you get a real number you have to use FP. My proposal uses the separator for a reason: works well with the new NTHTOKEN command:
Doing:
"." 1 NTHTOKEN --> Isolate the key
"." 2 NTHTOKEN --> Isolate the shift plane

I think it's simpler than using SUB to get the key value and plane. Not simpler than IP/FP though (hard to beat that).

(02-28-2017 10:54 PM)Vtile Wrote:  One major or minor issue with the string based keycodes are the harware compatibility if someone at some point in the future is willing to port the newRPL to different HW, the named keys might not be there. It still will brake the UI of ported nRPL programs, but the row&column coding makes more sense (atleast as I see it now, but hmm..) in that regard.

Just thought I spoke out what did pop to my head.

Let's think of the not-so-distant future when newRPL is ported to the Prime, for example. Let's look for example at the ENTER key. On the 50g it's at row 10, column 5, while the Prime has it at row 6, column 5.
So you write your program that WAITs for the Enter key... then you'll have to release a Prime version and a 50g version just because of the keyboard mapping.
However, with the string designation "EN" is Enter on both machines, regardless of where the key is physically located. Calculator keyboards will change in layout, but they all have numbers, operators, shifts, Enter, Backspace. Which alternative is more portable?

It's true that some keys might vanish from one platform to another (right shift), some become the same key (like 7 and Q on the Prime) and some are completely new (Esc, View) but in general, it will be much easier to port an RPL program based on the string description of the key than on the row/column.

(03-01-2017 01:05 AM)rprosperi Wrote:  Regarding the keycodes, I have 2 comments:

a. VTile's comment is a good one. Platform independence would certainly be easier using keyboard mapping by position, rather than what is printed on the labels.

Platform independence will never be achieved on a command like WAIT that deals with the hardware. The idea is to make it easier to port from one platform to the other one.
Independence can only be achieved if you map the keys on all new hardware to the same code that key had on the 50g keyboard. But then it won't mean row/column anymore so on the Prime you couldn't tell what's the Enter code unless you have a table printed in a book.

(03-01-2017 01:05 AM)rprosperi Wrote:  b. In many cases, newRPL has deviated from compatibility with RPL, but in every case I recall, there was some real benefit from the deviation, which justifies doing so (at least IMHO, there are no doubt folks here that want it 100% compatible, but then what's the point?).

Maybe I'm not following the discussion properly and don't have the right context, but it seems to me that the rc.p key code system that has been used in RPL forever should be retained, as the proposed string-based scheme is new, different, has no advantages, and is not compatible. Keep in mind too, that even if a couple folks here have not ever needed to use the numeric standard in the past it does not mean that no one uses it.

You don't see any benefit, hence your conclusion is correct. It would also be my conclusion if I didn't see any benefit, but I do:
Let's say a typical routine that reads an integer number directly from the keyboard using WAIT. You'll be dealing with the numbers, Enter, Backspace, and perhaps cursors left and right.
Such a routine would've needed changes even porting from a 48 to a 50g due to different keyboard layout. However, all those keys can be found on almost any calculator, so that newRPL program would run unmodified on practically any hardware. With row/column it would need a different version for each keyboard.

(03-01-2017 01:05 AM)rprosperi Wrote:  Claudio - you stated that the old-style key codes are hard to remember; I have to disagree as the point is you don't have to remember them at all, they are self-documenting by declaring their location in the key code itself. And while which plane is 1, 2, 3, etc. is not always memorized, it's no harder than the alphabet soup proposed, which in any case is mnemonic for English only.

Change for some benefit makes sense, but with none (that I see), it seems compatibility should be favored.

Do you still see no benefit?