Re: XPL question

[Harry Binswanger hb@xxxxxxxx]

Looks like XyEnc is moving in the direction of my old XyBasic. One
difference is that XyBasic proceeds on the recognition that XPL is
text-centered rather than code-centered, and that this was a mistake. I'm
guessing that the programmers of XyWrite didn't foresee that XPL would be
so powerful, so they viewed S/Gs as essentially for doing a few things with
text. But if you look at any XPL code, there's very little text in it. The
reserved words and operators far predominate.
 XyBasic proceeds on the infinitely more economical assumption that text
will be rare in an XPL program, and so text is set off with commas.
Everything else, the default, is assumed to be either logic or funcs
(introduced, as you do, by an apostrophe).
In other words, all your squiggles, the < ~ etc., are redundant. They're
just clutter. XyEnc, like XyBasic, could be set to interpret any IF as ≪IF
or, in your version, ~
So here's my XyBasic version of your your encoded XPL. It's case
insenstive, but I prefer lower case for ease of typing

'bc
first = inkey$
second = inkey$
if first > 0 then
  print "in first if"
  if second > 0 then
     print "in second if"
  endif
  print "past first endif"
endif
print "past second endif"
exit
If I've gotten your code's logic right, this "decodes" (translates) to the
same XPL as yours, and, like yours, it is plain ASCII. Also, XyBasic allows
commenting, introduced by a semicolon.

--Harry
  'BC
  ~~>
  ~~>
  ~in_1st_if___
    ~
      in_2nd_if___
      ~
    past_1st_ei_
    ~
  past_2nd_ei_
  ~
  ~Z

When you execute it, you enter 0 or 1 twice, to control how the IF
statements will evaluate, and the program then runs to completion, to tell
you where it's been.

This is my understanding. Please correct me if I'm wrong.

Now, in XyWrite III+, nested IFs are ostensibly "not allowed," but they
"work" in the sense that the above program "works," and in the sense that
both IFs must be true to get to the "in 2nd if" blurb. Not only that, they
are useful, because the 2nd IF can contain a clause that is not always
evaluatable (undefined S/G, for example) so long as it is evaluatable if
the first if is true. However, in XyWrite III+, the 1st EI effectively
"terminates" all open IFs. That is, the "past 1st ei" blurb is emitted
regardless of choice of inputs, and the 2nd EI is meaningless.

In XyWrite IV, nesting of IFs is allowed, so I presume I wouldn't get the
"past 1st ei" emit if the first IF evaluates false.

So, several questions:

1. Do I have this right?

2. This seems to represents an "incompatability," where a "working"
(although a not-by-the-book) XY III XPL program behaves differently under
XyWrite IV (despite Harry's constant claim of 99.99% backwards
compatability). Does that seem to be correct to you.

3. Have you seen a significant use of nested IFs, with a single trailing
EI, in practice under XyWrite III+?

TIA

Wally Bass

PS: I'm nearing a new release of the XYENC package. It will probably be
today or tomorrow.


Harry Binswanger
hb@xxxxxxxx