Re: What's the difference? (RPN/RPL)
Message #6 Posted by James M. Prange (Michigan) on 22 Feb 2006, 11:34 p.m.,
in response to message #3 by Garth Wilson
Quote:
As one who has never used or paid much attention to RPL myself,
perhaps I can ask further, for the original poster. I understand
RPL has strict program structures with no GOTO and, I assume, no
labels either;
True, and no GOSUB either, thus indeed no use for labels.
But subprograms can be placed and manipulated on the stack and
evaluated by the EVAL command, or stored as global variables and
evaluated by name, or stored as local variables and evaluated by
name followed by EVAL.
Quote:
and further, that an RPL program is compiled from text source code
instead of being keyed directly in like you would do on an RPN
programmable calc.
??? Well, ordinarily, I do key a program directly into the command
line, within << and >> UserRPL program delimiters. Of course, you
can always write a program (or most other object types) as source
code in a text editor and transfer it to the calculator. If I
happen to be at my PC, I'm more likely to use the larger screen
and QWERTY keyboard to write all but the simplest programs. But
for "real work", I'm not likely to be at my PC when I want to
write an "ad hoc" program.
There are different ways to get the "words" into the command line
editor; some can be placed there simply by pressing a primary or
shifted key, most of the rest by pressing a menu key, and you can
always just go into ALPHA mode and type out the command name.
Personally, unless I know that I'm going to be using several
commands from the same one or two menus, I normally just type out
the command names instead of navigating through the menus.
In the 28 series, all of the commands are available through the
CATALOG operation, and similarly, the 49 series has the CAT
operation. These are perhaps best used if you don't remember the
exact spelling of a command.
ENTER (or implicit ENTER) parses the command line, and assuming no
syntax error, compiles it to a "secondary" (a SysRPL program)
containing the object(s), and then executes it. In the case of a
UserRPL program, we enclose the program within the << and >>
delimiters, so "execution" simply places the UserRPL program on
the stack, and it's decompiled for the stack display. To evaluate
("run") the program, you can use the EVAL command. Or with the
program and a name on the stack, you can store them as a named
global variable, in which case, executing the variable's name
evaluates the program.
For that matter, you can write the object's source code, followed
by the global name and the STO command, all in the command line,
and then press ENTER to have them stored as a global variable
without ever seeing them on the stack.
"Vectored ENTER" allows you to take additional actions before
and/or after actually executing the command line.
Note that storing objects by name effectively extends the language
for that particular calculator, and on all but the 28C, you can
store quite a lot.
Note that RPL doesn't have "PROGRAM" and "RUN" modes. Perhaps the
closest you can come to those is switching between "immediate",
"PRG", "ALG", and "ALG PRG" entry modes, and "quoting" source code
with delimiters for delayed execution.
You can write your source code within a character string, thus
preserving all of your formatting and comments, and later
"execute" the string with the STR\-> command, if you prefer.
Quote:
I expect that variables can have names,
Of course; an RPL "variable" amounts to a "named object". But
there are some restrictions to names. For example, a global name
can't duplicate a built-in "key word", or start with a numeric
character, can't contain mathematical symbols, such as +, -, *, /,
^, <, and so on, can't contain any delimiter or separator
character, and is limited to 127 characters. Note that in the 49
series, some of the restrictions are ignored by the Filer's
"RENAME" operation and the S~N command in the "hacker's menu", but
the "invalid" names can cause problems. Local names have fewer
restrictions; for example, they can indeed duplicate built-in key
words.
Quote:
and that you can probably make different kinds of variables,
Well, variables are either global or local, stored with a global
or local name type object. A stored directory might be considered
a sort of global variable, stored with a global name, that may
contain other global variables. Global variables are stored until
the user purges them. Local variables are stored in a local
environment that exists only until the "defining procedure" (a
program or algebraic object) is finished.
Quote:
arrays, and data structures.
There are various types of objects, depending on the model.
In the 28 series, the "user" object types are real number, complex
number, character string, real array, complex array, list, global
name, local name, program, algebraic object, and (user) binary
integer. Of course the 28S can have directories, but you can't put
a directory "on the stack" in that model.
The 48 series adds graphic object, tagged object, unit object,
XLIB name, directory, library, backup object, built-in function,
and built-in command to the "user" objects.
The 49 series adds user types (exact) integer, mini-font, symbolic
array, and font.
There are also various "system" object types that the user
wouldn't ordinarily see, such as system binary, extended real,
extended complex, linked array, character object, code object,
library data, and external objects.
Note that SysRPL uses different terminology for the object types.
Quote:
Is this all correct?
Well, I hope that I'm correcting any misconceptions.
Quote:
Does it compile "words" into a dictionary like Forth does? Perhaps
these will bring to mind other things about it to describe briefly
as well.
I'm not familiar with Forth.
RPL compiles "words" (source code) into "objects". Certain
"built-in" objects are compiled simply as 5-nibble addresses,
other than that, each object starts with a "prologue address"
(usually referred to simply as the "prologue"), which is a
5-nibble pointer to the actual prologue, the code responsible for
handling the particular type of object. Some object types contain
information on the length of the object, or information that can
be used to compute the length. Lists, programs, algebraic objects,
unit objects, and symbolic matrices use the system object SEMI as
a closing delimiter.
Note well that RPL never stores source code as such; the closest
you can come to that is to force it to compile it as a character
string object. For display, Kermit "ASCII" transfer, printing "via
wire", and the \->STR command, objects are decompiled. But note
that the object types library, backup object, mini-font, and font
can't be decompiled by these methods.
Actually, having an object "on the stack" is a bit of indirection.
The stack is really a stack of 5-nibble pointers to objects that
exist elsewhere in memory, which are decompiled as needed for
display. So the stack manipulation commands don't deal with
objects per se, rather simply with 5-nibble pointers.
Note that an "algebraic object" could be regarded as a special
kind of program. It's entered in algebraic syntax between
single-quotation mark characters as the source code delimiters. It
has its own prologue, but other than that it's compiled as an RPN
sequence with SEMI as the closing object delimiter. For display
and so on, it's decompiled to algebraic syntax. Of course, it
can't use all of the "commands", only the "functions". That said,
you can often write your own "user-defined functions", which can
then be used within algebraic objects. All algebraic objects can
be re-written as programs, but not all programs can be re-written
as algebraic objects.
Regards,
James
|
Go back to the main exhibit hall