I thought folks might be interested in knowing about this nifty
feature in the hp48G/GX calclators. The original post came from
comp.sys.hp48.
-benjy
Subject: G/GX Auto List Processing Update
In article <··························@hpcvbbs.cv.hp.com> ············@hpcvbbs.cv.hp.com (Joseph K. Horn) writes:
G/GX "AUTOMATIC LIST PROCESSING" UPDATE
---------------------------------------
"List!" -- Shakespeare
It's been said that the G/GX handles the new "list processing" ability
not by adding new entries to every command's Check&Dispatch table, but
in the error handler. This still didn't answer the question: How does
it *know* which functions allow lists and which don't? I called James
Donnelly and here's the scoop.
The Check&Dispatch routine's own error handler, which is only run when
the object-type table is exhausted without finding any match, has been
modified (he says it didn't take a lot of code) to see if the function
is a "control structure" (like DO, FOR or THEN); if so, it immediately
errors out. Otherwise it checks if the command takes a varying number
of things from the stack (like DROPN); if so it errors out. Otherwise
lists are accepted as arguments and looped through, placing all of the
results (if any) into a list. Since the commands that don't do object
type verification (like DROP) never error out due to an illegal object
type, they can't use automatic list processing.
Notice that automatic list processing practically creates one of those
things that we were all asking to be in the G/GX: symbolic arrays. For
example, 7 { 3 X } * --> { 21 '7*X' }. Remember all that looping we
did between OBJ-> and -> LIST? No need; now it's all automatic.
Although the list of commands that have this power is finite, you will
be able to bequeath that power to anything at all, even your own user-
defined functions, with the new DOLIST command, which means: "evaluate
the object on level 1 using as its input the elements from the list(s)
on the stack above it and return the results (if any) to a list." For
example, if I want to run my one-argument user-defined function called
'UDF' on the elements of a list and return the results to a list, this
is what the S/SX requires:
OBJ-> -> n << 1 n START UDF n ROLL NEXT n -> LIST
But this is how easy it is on the G/GX:
'UDF' DOLIST
A lot of commands accept lists even though doing such a thing would be
stupid. For example, Jim says that a beta tester thought that he found
a "bug" because when a list was used as the input for the RES command,
it only seemed to use the list's last element. Ha! It really set RES
to the first element, then the next one, and so on, happily doing just
what it was told to do. IMHO this is a good thing, because adding the
logic (and/or lookup table) required to weed out the "stupid" commands
would surely slow the machine down.
I have a powerfully strong hunch that automatic list processing is not
appreciated because it is so novel (in a handheld). I hope that a few
of the LISP experts out there can post some of the tricks of the trade
that they've learned in that list-oriented language so that we can use
them in G/GX RPL.
-Joe Horn-