Re: XPL question

[Carl Distefano cld@xxxxxxxx]

Wally:

You have it right. However, it wouldn't be fair, in my view, to
characterize this as an "incompatibility" between Xy3 and Xy4.
"Compatible" in this context means that features that are common to the
two programs work the same in Xy4 as they did in Xy3. That is undeniably
true to a very large extent. Nested IFs, however, are a feature that Xy4
supports and Xy3 doesn't. There are many such features, notably the
myriad of functions, commands, command switches, and XPL operators that
were introduced with v4. The fact that these new features work
erratically or not at all in Xy3 doesn't refute the claim that retained
features work the same.

To put it another way, nested IFs are a feature in Xy4, but an error in
Xy3. Your nested-IF example works -- to an extent -- in Xy3 because Xy3
tolerates the error. That is, instead of simply returning "Command entry
error", it executes the instructions until it encounters the first EI.
You can exploit the tolerance if you know what you're doing. But
standard Xy3 code should not contain nested IFs, and most of my and
Robert's Xy3 code does not.

Speaking of such matters, here's another example of how a feature that
exists in Xy4 but not in Xy3 can be exploited to useful effect. The
program below is a Xy3 version of the U2 XYENCode-XYDECode routines for
Xy4 that I posted last week. It runs in Xy4, too, but I wanted to tweak
a couple of instructions to make them more idiomatic for Xy4 when the
routine is run under Xy4. The "Test for Xy4" below (SUb 04) takes
advantage of the fact that a SUbroutine containing Xy4-only code (in
this case, a string comparison using quoted strings) will run in Xy3
*until* the Xy4 code crashes the SUb. For this reason, the values that
the SUb assigns to S/Gs 05 and 06 after the quoted strings are
encountered will take effect in Xy4, but not in Xy3.

By the way, this program is slightly different from the U2 frames in
that the encoded or decoded material *replaces* the original. I've
modified the U2 frames to do that, too. I think, in practice, this will
be the most useful behavior. It's a snap to toggle between encoded and
decoded versions, so I don't think there's any downside to this change.

I'm looking forward eagerly to the update to XYENCode.

- - - - -

~_XYCODE.PM_-_CLD_1/15/09_(instructions_below)'^
~~~>
~<>1~>
  ~~
  ~
~~>~
~)<1'|@upr(~)==~~>
  ~
  ~
~
~~{@upr(~)==0~>
  ~
  ~
~~>
'BCd_eb=0,0'XC
~~~>
~<1~>
  ~'DX'YD'XP'TF'DF'BF'DF~
  ~
'DF~~>~~>
~==~~>
  ~
  ~
~'BCernv_~xy~.in'XC
'BCernv_~xy~.out'XC
'BCsad_~xy~.in'XC
~~>
  ~~
  ~
'BCwait'XC
~
  ~~
  ~""~>
   ~~
   ~~>
  ~
'DB'DO'FF
'BCdos~_/c_xy~.com_._
~xy~.out<~xy~.in'XC
'BCwait'XC
~~
~>2~>
  ~
  ~
'BCexist_~xy~.out'XC
~~>
  ~+1~>
  'BCp_1'XC~
  ~
~'BCexist_~xy~.out'XC
~~>
  ~~
  ~
'GT'DO'FF~'DX~~>
'BCme_~xy~.out'XC
~~>
  ~~
  ~
'BCwait'XC
'BCernv_~xy~.out'XC
'BCernv_~xy~.in'XC
~~>
'BCseba__'?Z'XC
~)&~==~-2~>
  'RC'RC
  ~
'BCjmp_~'XC
'BCd_eb=~'XC
'BC'GT'DO'FF~~'^
'^
--_'^
XYCODE.PM_--_CLD_1/15/09'^
For_XyWrite_III+,_XyWrite_IV_and_Nota_Bene_for_Windows'^
'^
Purpose'.'^
Encode|Decode_Current_File_or_DeFined_Block'^
__Using_Wally_Bass'`s_XYENCode|XYDECode_Utilities'^
_(see_XYENCDEC.TXT_for_documentation)'^
'^
Required_External_Programs'.'^
XYENC.COM_and_XYDEC.COM_must_be_in_the_DOS_Path'^
'^
Usage'.'^
With_file_or_DeFined_block_in_current_window'.'^
__RUN_XYCODE.PM_E[ncode]'^
__RUN_XYCODE.PM_D[ecode]'^
'^
Encode_variants'.'^
__RUN_XYCODE.PM_ENCL'^
__RUN_XYCODE.PM_ENCH'^
__RUN_XYCODE.PM_ENCLH'^
XYENCL.COM,_XYENCH.COM_and_XYENCLH.COM,_respectively,'^
__must_be_in_the_DOS_Path'^
--_'^

- - - - -

--
Carl Distefano
cld@xxxxxxxx