Re: XPL questions

["Robert Holmgren" holmgren@xxxxxxxx]

** Reply to message from "Patricia M. Godfrey"  on Sat, 11
Mar 2006 19:03:33 -0500


> 1. What should you do when BALPAIRS asks you to choose a set? I type
> Ctrl+>, to get the guillements, and all that happens is that I get a
> message "Abort."

When you run BALPAIRS, you get this PRompt:
"Pick a char from ONE set: |()|[]|{}|<>|`'|/**/|". So, in response, you type
a (one!) character from one of the *available* sets: a parenthesis (either
one), a bracket (either one), a curly brace etc etc. I do not see guillemets
among the available sets, I see only varieties of brackets, braces, parens,
apostrophes, and Rexx
/* comments */.

> 2. How come U2 repeatedly uses ≪sx01,≪IS50≫≫, but
> when I try it I'm told "SX requires a number"? (Yes,
> I've read PARSEFRM.DOC, but I'm still not sure if I
> have to call some other frame to get what is typed
> on the CommandLine into SG 50; TESTPRS doesn't seem
> to, but...)

Let me review some of the basic principles.

We (authors of U2) selected Save/Get 50 to pass arguments to and from every
frame in U2. The choice was somewhat arbitrary, but... not really: S/G 50
lies dead in the middle of the range of transient Save/Gets (01 through 99).
Most programs should use transient Save/Gets, because they don't retain memory
after a program closes. We reasoned that the first 49 Save/Gets could be used
for program variables, and the last 49 transient Save/Gets (51-99) could be
used for development of new frames, or processing of child frames, or other
transitory purposes. Now, I know of no program which uses more than 49
Save/Gets, and only an idiot would try to use that many, because the program
would surely go OOM. Smart programmers re-use Save/Gets; when the data stored
in Save/Get 02 is no longer needed, you use S/G 02 for a new purpose *instead
of* using a brand-new S/G 03 (and leaving the useless data in S/G 02 hanging
around to clog memory).

Now, the real (and only) Save/Get that automatically reads the command line is
S/G 00. So why, then, do we need S/G 50? Because S/G 00 is highly volatile
and unreliable. It changes value constantly. S/G 50, OTOH, is highly stable
-- all the transient S/Gs are stable during the execution of a program EXCEPT
for S/G 00.

This is where the  comes in. The  is simply an ordinary XPL
frame that parses the command line into two components: framename and
argument(s). It puts the framename in VAriable $FR, and it puts the
argument(s) in Save/Get 50. Because all other frames in U2 are built to expect
arguments in S/G 50, the  needs to be called first when launchinig a
frame from the CMline. You could legitimately argue that every frame in U2
that is called from the command line is a "child" of the  frame (the
actual framename of the  is PRSCMLINE -- PaRSe CMLINE).

Now, suppose that you've written a frame (a program) and merged it into U2.
Suppose that at a certain point your program needs to call another frame in U2
as a "child frame". Let's take a concrete example. Suppose you have stored a
particular CursorPosition (using the  command, e.g.  command
-- and then, after you stored that , your program toggled the document into
Draft view mode/No markers. What happens now? There's NO WAY to relocate the
cursor between the F and the L, because the embedded command has disappeared!
A JuMP will position your cursor either before or after the embedded , but
not within it -- because the  is now hidden by draft view. Think about it:
there are many situations in which this might happen. Suppose you store a
CursorPosition which immediately precedes a three-byte hyphen, and then suppose
you delete ONE character earlier in the document. To try to return to the
stored position would put you smack in the middle of a 3-byte character, and
that is illegal -- three-byters are indivisible units. But consider: earlier
we constructed program code to keep JuMPing until we returned to the exact
CursorPosition that was previously stored! Since that is now *impossible*, the
results are: 1) an endless loop and hung program, 2) complaints on this
maillist, and 3) longwinded explanations like this.

So what do we do? Shut down the maillist? There's a fair amount of XPL logic
embodied in the problems and workarounds above -- 85 bytes worth, to be
precise. Do we repeat that logic over and over every time we want to return to
a stored cursor position? No! We call a single child frame, readily
accessible to all other frames, called REJUMP: it attempts the JuMP three
times, and then gives up if it hasn't yet returned to the exact stored spot
(because it simply can't). When the child frames terminates, execution returns
to the "parent" frame, which continues apace. Program does not hang.

Now, to "call" REJUMP, we need to supply an argument to it, namely the stored
CursorPosition. Since the rule is that all arguments are passed to all frames
in Save/Get 50, but whoops, we *still need* the argument data that was
originally supplied to the parent frame **also via Save/Get 50**, THEREFORE one
of the very first things we might do in any frame that expects to call a child
later is to get that data *off* of S/G 50 and into another Save/Get where it
can be safely stored and not lost. Hence we might say (and we often DO say)
" to launch your frame, or you
didn't put any data into S/G 50 manually! S/G 50 does NOT automagically, or
inherently, hold data in XPL. Inherently, it is empty and uninitialized. YOU
must initialize it, and put data into it, either directly or indirectly (e.g.
via ). One of the virtues of the  is that, even if your
frame makes no use of arguments, it initializes S/G 50 anyway, but leaves it
empty -- therefore you don't get an "SX requires a number" error. (That error,
BTW, does not necessarily mean that you didn't supply a *number*; rather, it
means that there is a coding error: either a S/G which your program assumes to
have content doesn't yet exist, OR you've confused alpha and numeric data
types. It ALWAYS means that YOU have made a mistake.)

-----------------------------
Robert Holmgren
holmgren@xxxxxxxx
-----------------------------