DIR . . . END Structure
Bruce Jones
noticed a set of commands that I have not been able to find
documentation for. I've searched the site and the HP-48 FAQ.
Basically the commands seem to be used as follows:
DIR
'abc'
object1
'def'
object2
END
If these commands are stored in a variable named 'xyz', then upon
executing the object a directory named 'xyz' is formed under the current
directory, with two variables named 'abc' and 'def'. These variables
hold the objects that come directly after; these objects could be
programs, grobs, lists, etc. The DIR . . . END 'structure' seems to be
part of the 'top level' HP-48 language; at least the programs I've seen
it used in are not written in User or System RPL.
Do I understand how this structure is used? Are there any other nuances
I haven't observed? Are there any other similar commands that are not
officially documented? Is there any documentation at all on this or
other similar commands?
Thanks,
Bruce Jones
Peter Karp
<bruce...@erols.com> wrote:
>I've been looking at some of the programs at www.hpcalc.org, and I've
>noticed a set of commands that I have not been able to find
>documentation for. I've searched the site and the HP-48 FAQ.
>
>Basically the commands seem to be used as follows:
>
>DIR
> 'abc'
> object1
> 'def'
> object2
>END
>
>
>If these commands are stored in a variable named 'xyz', then upon
>executing the object a directory named 'xyz' is formed under the current
>directory, with two variables named 'abc' and 'def'. These variables
>hold the objects that come directly after; these objects could be
>programs, grobs, lists, etc. The DIR . . . END 'structure' seems to be
>part of the 'top level' HP-48 language; at least the programs I've seen
>it used in are not written in User or System RPL.
>
>Do I understand how this structure is used?
Yes. It's not really an undocumented program feature, but the ASCII
represantation of a directory.
Those DIR END structures come after the usual ASCII header.
Little example:
%%HP: T(3);
@T(3) tells which translation to use
@look up the details in your manual
DIR
EQ 'SIN(X)'
GlobalVar 35
Program \<< 1.16 * \>>
END
or something like that.
@those lines are comments
and will be stripped out of the program when transfering them to the
calc.
You can snip those programs, save them as pure ASCII files on your PC
and then transfer them via Kermit (using ASCII mode) to your HP48/49.
Vice versa you'll receive such an ASCII file on your PC when
transfering from the HP.
[48 only:
A real marvel dealing with those ASCII files is John H. Meyers program
Urpl which allows to transfer an ASCII file with the faster binary
mode, but convert_it_back/make_it_ready after/for import/export. The
program saves batteries on a real HP48 and allows to import ASCII
files to Emu48 easily. I don't remember the name of the file on
hpcalc.org, but I hope someone other can name it off the top of the
head. Must be somewhere in the Emu48, Transfer or Misc section of the
HP48].
Greetings from Cologne
Peter
--
Great HP48/49 links:
http://www.engr.uvic.ca/~aschoorl/faq/
http://www.hpcalc.org
to find *old* postings search http://www.deja.com/home_ps.shtml
Veli-Pekka Nousiainen
news:3990DF1A...@erols.com...
> I've been looking at some of the programs at www.hpcalc.org, and I've
> noticed a set of commands that I have not been able to find
> documentation for. I've searched the site and the HP-48 FAQ.
>
> Basically the commands seem to be used as follows:
>
> DIR
> 'abc'
> object1
> 'def'
> object2
> END
>
>
> If these commands are stored in a variable named 'xyz', then upon
> executing the object a directory named 'xyz' is formed under the current
'xyz' RCL would give you the directory into the stack
in a format you have described.
Use NEWOB or STOre it into another variable before
any manipulation or experiment by directly editing the
directory "shortcut" in stack.
Happy experimenting :-D
VPN
PS: DIR is documented in the 48 docs.
> directory, with two variables named 'abc' and 'def'. These variables
> hold the objects that come directly after; these objects could be
> programs, grobs, lists, etc. The DIR . . . END 'structure' seems to be
> part of the 'top level' HP-48 language; at least the programs I've seen
> it used in are not written in User or System RPL.
>
Joseph K. Horn
> DIR
> 'abc'
> object1
> 'def'
> object2
> END
>
> Do I understand how this structure is used?
Yes. However, DIR END is not a programming "structure" (like START
END), nor is DIR a command really; it's an OBJECT DELIMITER (like << >>
). A directory is an *object*, of type 15. The object types and their
delimiters are well documented. You should learn all of them before
doing anything else (except breathing).
To illustrate the difference between a program structure and an object
delimiter: You can't have START END sitting on the stack by itself; they
have to be embedded inside a program. But you can have DIR END on the
stack. In RPL, "object" = "anything that can occupy one stack level all
by itself".
> Are there any other nuances I haven't observed?
Here's a strange one: modifying the contents of a directory in memory
will also modify any referenced copies of that directory on the stack.
Try it; it's really freaky.
> Are there any other similar commands that are not officially
> documented?
Like GROB perhaps? Check your manual for a description of the various
object types. It's all in there.
Hope this helps!
-Joe-
Sent via Deja.com http://www.deja.com/
Before you buy.
David Fabiani
Joseph K. Horn <joe...@jps.net> wrote:
>
> Yes. However, DIR END is not a programming "structure" (like START
> END), nor is DIR a command really; it's an OBJECT DELIMITER (like <<
Right, but there's also a DIR command (which does nothing at all)
Try 1792 27 XLIB~ (menu 256, last page)
As a matter of fact the related program is, on my HP49g ROM 1.18,
stored at address #38BAEh, and is a nop empty program ("D9D20B2130")
If I remember well it was the same on the HP48 SX/GX.
I never figured out why such a DIR command has been implemented.
David Fabiani
Veli-Pekka Nousiainen
VPN
"David Fabiani" <david_...@my-deja.com> wrote in message
news:8mv4mf$7r3$1...@nnrp1.deja.com...
Joseph K. Horn
> I never figured out why such a DIR command has been implemented.
The DIR command is supposed to be used only for command-line parsing and
for object decompiling when displaying, editing, and printing
directories. It's never supposed to be executed directly. There are
many other "objects" which likewise don't do anything whatsoever other
than act as place holders or object delimiters; for example, the tic
character ['], the hash character [#], GROB, IF, CASE, UNTIL, END (after
IF), THEN (after IFERR), C$, C#, XLIB ... maybe more.
-Joe-
Veli-Pekka Nousiainen
Joe has got it right (one more time :)
You may try putting your IF in various places
in your program.
VPN
PS: What is "Ranger" ?
"Joseph K. Horn" <joe...@jps.net> wrote in message
news:8n0ftn$746$1...@nnrp1.deja.com...
John H Meyers
> Here's a strange one: modifying the contents of a directory
> in memory will also modify any referenced copies of that
> directory on the stack. Try it; it's really freaky.
It may have been Donnelly who explained why, in this forum
(after I naively asked :)
It is possible to even have the HOME directory on the stack;
if the calc presumed to make a NEWOB of that, just because
any variable was stored/purged, anywhere (including in the
hidden directory), then you'd need a complete new copy of all of
HOME (which might be too big to copy in existing free memory).
So, a directory is an exception to the rule that a new copy
is made of any object on the stack when the contents of its
original location (e.g. in user memory) undergo change.
-----------------------------------------------------------
With best wishes from: John H Meyers <jhme...@mum.edu>
John H Meyers
> DIR is an OBJECT DELIMITER like \<< and \>>
Hmm.. \<< and \>> are each themselves an object,
of type 19 (Command), and those objects are generally
contained within a program object (more later about this).
Maybe we should introduce the words "compiler" and "decompiler"
here, in case this will help in the examination of what's
going on here.
When the calc displays objects (one stack level contains one
object), it examines the internal binary stuff, and creates
some text for human eyes to understand and interpret it,
using the calc's built-in "decompiler"
Sometimes an object is represented by a single word of text,
e.g. most commands and functions, like DROP or COS etc.;
other times, particularly when the object itself contains
inner objects, there is generally shown some text to indicate
the beginning and end of the "composite" object (a directory
is not strictly one of those, as SysRPL defines "composite,"
but we're taking poetic license here :)
The calc shows you the text "{" and "}" surrounding lists,
for example, and "[" and "]" surrounding arrays. Conversely,
it's desirable that after you edit such text, the built-in
compiler should understand the syntax and turn it back into
composite (or "compound") objects again, so these characters,
which have been referred to as *delimiters*, are the text
characters which the compiler (and you too) need, for
understanding where the collection of "inner pieces"
begins and ends, so the decompiler generates these characters
in the first place, and the compiler understands them again.
The words DIR and END are what the decompiler spits out,
surrounding the contents of a directory, so that you know
what sort of pile of stuff you've got there, and likewise,
the compiler understands that too, so you can actually edit
a whole directory at a time in UserRPL, if you so choose
(your only problem will be how to store it over an old one :)
Thus, DIR and END can be considered "delimiters" as well.
However, spoiling the neatness of the whole idea, it so happens
that "program delimiters" are actually not delimiters; rather,
they are actually commands! It so happens that what the decompiler
shows for the beginning and end of a program object is -- nothing!
(When you try to decompile SysRPL programs, you don't see any
so-called "program delimiters," do you?) In UserRPL syntax,
however, it is compulsory for you to surround your "programs"
with the symbols \<< and \>>, and the compiler uses those
symbols to make things which end up acting like programs,
even though there are several little hidden things going on
inside them, which Dr. Bill Wickes & Co. thought you would be
better off not having to know or care about (if you are only
a UserRPL programmer), so they made the actual "ends" of the
internal "program" type of composite object completely invisible.
> You can't have START NEXT sitting on the stack by itself;
> they have to be embedded inside a program.
{ START NEXT } 1 GET looks pretty convincing, however,
as does { IF 1 THEN 2 END } 1 GET :)
Actually, it's true that what's left on the stack here is
really a program (with its invisible or non-existent delimiters), in
which each word START and NEXT is a separate command object (type 19);
this is a result of the compiler having been crafted not to
let the commands START and NEXT (and anything between) become
separate elements of the list, so the whole START ... NEXT section
gets packaged into a program, as a single object within the list.
Library 1792 contains entries for the "structure" words of UserRPL,
which assist the compiler in doing its job. I thought that some
of these even used to have "directory tabs" on their names in the
HP48, but maybe my memory is fuzzy; anyway, these are related
syntactical elements, not just isolated "commands" in their own right.
Man, that compiler (and the whole RPL system) is pretty smart,
isn't it? (or whoever invented it must have been)