Date: 15 Jun 90 22:53:06 GMT
From: steveh@hpcvra.UUCP  (Steve Harper)
Organization: Hewlett-Packard Co., Corvallis, OR, USA
Subject: Re: Assorted HP48 questions
Message-Id: <25590015@hpcvra.CV.HP.COM>
References: <8815@hacgate.UUCP>
Sender: handhelds-request@csl.sri.com
To: handhelds@csl.sri.com

It does seem an obvious enough requirement to be able
to access an object "downstream" in the directory
structure (or "upstream" and then back down some other
branch), doesn't it?  How could we be so foolish as to
leave something like that out of the 48?  Well, we
weren't and we didn't.  I was going to say that all
you have to do is look on page such-and-so of the
manual... but if it's in there, I can't find it (:-(!
This must be something reserved for the reference
manual...

1. In the 28, if you EVAL a list, nothing happens.
It just returns the list, which is data.  On the
48, this was changed.  If you EVAL a list, the
individual objects in the list are EVAL'd in
order...essentially the same as a program.  So...
If you do something like {dir1 dir2 dir3 prog} EVAL,
the machine will search for dir1 in your current path,
and if it finds it, will make that your current
directory.  From there, it looks for dir2, which
can of course be a sub-directory in dir1, and makes
it the current directory.  Then the search continues
for dir3, etc, and then prog, which is a program, will
get executed... er, EVAL'd (sorry, Bill!).  This is
all well and good except that your current directory
is now dir3, which is likely not what you wanted.
The purpose of the SVC program in the previous
response was to accomplish what EVALing the list
does, but in addition to return the current directory
to what it was before.  Well, it turns out there is
some special code in the RCL function... If I do
this, for example: {dir1 dir2 dir3 prog} RCL, the
same searching takes place as before, but the current
directory does not change, and the object (prog, in this
case) is returned to the stack (RCL'd, not EVAL'd).
If it was a piece of data I wanted, I'm done; if it was
a program, I just do an EVAL after the RCL to execute
it (ooh, there's that word "execute" again...).  So you
can access objects anywhere in the directory structure
from anywhere else.  You just have to know the "path"
and put it in a list preceeding the object and then
RCL that list.  This is similar to a DOS or UNIX
path, except that in the 48, you have direct access to
anything upstream of your current directory without
having to specify it.

2. This same syntax can be used to EVAL or RCL objects
in the directory structure of a backup object.  Let's
say your favorite application consists of several
data variables and several programs and subroutines all
stored in a directory called 'app'.  You can save the
whole kit and kaboodle in the independent ram card in
port 2 by doing: 'app' RCL 2:app STO.  Now you can pull
the card (turn the machine off first...) and give it to
a friend or put it on the shelf for safe keeping.  Now
one day you or somebody else puts the card back in a
48 and wants to restore, not the whole application, but
only one little subroutine down in a sub-directory of
'app'.  2:{app subdir prog} RCL brings it back.  If the
object is a program to be EVAL'd, you could use EVAL
directly and skip the RCL step.  The machine will not
let your current directory reside in a backup object, so
the RCL isn't necessary here.  Forget which port your
card is in?  The wildcard character "&" instead of a
port number in the tagged backup object will cause the
machine to search port 2, port 1, port 0, and then
even search main ram to find the object.  &:obj RCL
will RCL obj from port 2 if it's there.  If not, then
it will RCL it from port 1.  If no luck there either,
it will try port 0, and if it still hasn't found obj,
then it will look in the current path in main ram.

Remember, to keep the parser happy, the tagged object
in the command line has two colons, like this: :2:obj.
The first one goes away when you press enter and put it
on the stack: 2:obj.  This is why, when you enter the
colon to the command line, you automatically get two of
them... except in alpha mode...

Neat, huh???  Hope this helps....

Steve