Re: XPL question

[cld@xxxxxxxx]

Wally:

You have it right. However, it wouldn't be fair, in my view, to characterize this as an
"incompatibility" between Xy 3 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