Hi Ernie,
you're missing my point.
Maybe so. I do see your point that RPN and RPL are different, and I
agree with that. But I think that RPL is easy to understand and well
worth learning. "Classic RPN" has to run on hardware with relatively
limited resources. The RPL calculators have, if I'm not mistaken, faster
processors, and certainly more built-in memory (well, possibly excepting
the 28C), so why shouldn't RPL take advantage of the improved hardware?
Why, for example, would one want to restrict the stack to only four
levels? Or to save only one last argument? I see RPL as an improved
version of RPN.
As I mentioned in an earlier post, I wrote the example programs
off the top of my head without testing or optimization.
Ok, it's a simple enough example that it doesn't really need any
testing. Well, at least not the RPL program, which will obviously work;
I'm not about to buy myself a 41 and learn to program it just to see if
the 41 program works. But I glanced at your RPL example, and off the top
of my head, I couldn't see any reason to go to the bother of using a
local variable. Now that I've thought about it a bit, I see that using
the local variable gives your version the advantage that it's a user
defined function; that is, it can be used in an algebraic object. But
about the only time that I use algebraic objects is when I'm copying a
formula that's already been written down by someone else, and seldom
even then.
>why would you want fancy formatting when a program's on the stack?
And that points to another design flaw. Programs are meant to be
read by _people_, because they have to be understood by _people_ if they
are to be modified, improved, or what-have-you. Removing the "fancy
formatting" removes understandability and confuses the programmer. Good
coding standards _require_ use of comments and indentation whenever
possible.
I think that you're missing *my* point here. My point is that if I
wanted to peruse a program and perhaps edit it, I wouldn't be looking at
it on the stack, but in the editor, where I could scroll through it and
see the entire program, or I'd print it out, and with those methods it
does have the indenting (although the indenting is what the decompiler
applied; not necessarily what I would have used). Or better yet, if I
wanted a really good look and I wrote it on the PC, I'd be looking at
the source file, indented and commented as I saw fit (of course, that
would require that I be at home so that I could use my PC). And yes,
good programming practice requires the use of comments and indentation
in the *source* code whenever possible. But for simple programs, someone
familiar with the programming language can look at the code and see what
it does even without indenting or comments. I do use indenting, and,
when I write a program on the PC, some comments in the source code, but
do you know of any compiler that retains the indenting and comments?
Wouldn't that defeat much of the purpose of compiling?
To be sure, there are languages that save the source code and interpret
it at run time, but I have my doubts as to how feasible it would've been
to use that method on a hand-held at the time that UserRPL was designed,
or even now.
>If I really wanted to keep the program from being compiled, I could
embed it within a character string and even keep comments in it
Come, now, who's making things more difficult than they have to
be? 8^)
Well, you complained that the RPL compiler discarded the programmer's
formatting, so I demonstrated that you could make it retain the
formatting if you really wanted to. I certainly don't recommend that
anyone use that method; keeping the source code in its own file on the
PC makes a lot more sense.
>RPL is simple and straightforward.
Debatable and subjective. It's equally possible to argue that
RPL is complicated and convoluted.
Certainly you can write complicated and convoluted programs in RPL if
you choose to do so. I suppose that the same could be said of any
language. How about the 41's version of RPN? Using GTOs, I suppose that
you could make things *extremely* complicated and convoluted if you
chose to do so.
>As long as I use a variable name descriptive enough that I remember
what the program was written for in the first place
RPL variable names are, in practice, limited to 4 or 5
characters because more than that won't fit in a menu key label.
Sometimes my HP-28C can't put more than 3 characters! One cannot be
descriptive when limited to such short variable names. I should know --
I've been an RPG programmer for 20 years, and RPG II and RPG III program
variables are limited to 6 characters. Yech!
Haven't you ever noticed that in "PRG ENTRY" mode, pressing the menu key
for a variable puts the whole name in the command line? There, if it's
too long to fit in the 22 character standard display, you can scroll
left or right to see the rest of it. The name can be up to 127
characters, which I suppose should allow one to be descriptive enough.
The first few characters that you can see in a menu should be enough to
give you a clue, and on any RPL calculator except the 28C, you can
organize your variables into directories, which should give you more
clues as to what a variable is for.
>But I thought that the "RP" in both "RPN" and "RPL" stood for "Reverse
Polish". Doesn't that mean arguments first, operator last? Notice how
many of the arguments in your program come *after* the operators? Now
that's what I call backwards.
As mentioned above, programs are meant to be read by _people_. People
use human speech (with a given language) to communicate ideas. When you
say "store in register 01" you use a verb in the imperative tense
("store") and an object or "parameter" ("in register 01"). That's the
_natural_ way to speak.
Natural in English, which most often uses a "Subject Verb Object" word
order, but perhaps not for various other languages. But doesn't "1 plus
2" sound more natural than RPN's "1 2 plus" to our English accustomed
ears? Yet we (the folks on this forum, that is) prefer to use RPN.
Like Yoda of the "Star Wars" saga, you can say "In register 01
store," but taking this backwardness as far as that doesn't clarify a
program in the least.
I wonder which word order he uses in foreign language versions of those
movies.
For that reason, I feel that RPL is more backwards than RPN.
IMHO, HP took Lukasiewicz's invention just too far.
But suppose that the "objects" for "verbs" such as STO, RCL, FOR, or
flag commands are already on the stack, as a result of a previous
operation? If I have to put the "objects" after the "verb", then I
suppose that I'd have to push the "verb" onto the stack, and then
rearrange the stack to get the "objects" to the bottom of the stack, or
maybe write them down on a scratch pad and key them in again. That's the
genius of the "Reverse Polish" way of doing things; it lets you easily
use the results of previous operations.
Why do things differently for certain commands just to conform to
English language patterns? I'd rather that a programming language be
self-consistent.
Not that RPL is perfect of course. If it were up to me, then "IF" would
be discarded as it's superfluous in RPL, and for some commands that
require more than one argument, the order of the arguments seems
"unnatural" to me. The REPL command comes to mind; I experimented the
last time that I used it. Certainly I can imagine many additional
commands that I'd like to have built-in, "Garbage collection" can take
an awfully long time under certain conditions, and I could no doubt
think of other things that I'd rather were different.
But, as you yourself said, "stick with what you like."
Certainly. I have RPL calculators and a 16C. In some ways I find the 16C
inconsistent and rather limiting, but it's occasionally useful because,
being a rather specialized calculator, it has some special capabilities
that aren't built-in to the RPL models (though I suppose that I'd
program them in myself if I used them very often). But having RPL
models, I doubt that I'd ever really use other RPN models. What could I
do on them easier than I could do it on an RPL model? Something that fits
in a shirt pocket would be nice, but considering current prices, I'll
put up with a Brand X algebraic input calculator when I want to compare
prices in the grocery store. The RPN models are interesting and often
admirable in design and quality, but for me, they'd end up being museum
pieces, just left on a shelf or stored away somewhere.
>And then add the lack of IR, crippled serial I/O, flakey keys, poor
keyboard layout, lack of keyboard overlays, big ugly chunk of plastic
over the display, hard to read lettering on the faceplate, numerous
operating system bugs...
You just gave a precise description of the HP-49G! 8^)
Some steps forward, some steps back. The 49G is sometimes fun to play
with, and has some new operations that are useful, but for "real work",
I'll keep using the 48 series calculators.
Regards,
James