home *** CD-ROM | disk | FTP | other *** search
/ CP/M / CPM_CDROM.iso / jsage / znode3 / z3doc / z33if.msg < prev    next >
Encoding:
Text File  |  1993-06-07  |  3.3 KB  |  69 lines
  1. OK.  After all that bad publicity in the latest Z-News, I just had to
  2. dig into the flow control code and find out why "$1=//" was not the
  3. same thing as "//=$1" (we all know that equality is commutative,
  4. right!).  Well, here is the scoop.
  5.  
  6. The transient IF.COM flow processor for ZCPR33, called Z33IF,
  7. implements a large number of extended conditional tests.  Among them
  8. are the following (run "IF //" for a full help screen listing them):
  9.  
  10.         IF > token1 token2              IF GT token1 token2
  11.         IF <= token1 token2             IF LE token1 token2
  12.  
  13. These tests follow the conventional testing syntax in which the test
  14. operator is given first and the operands follow.  These tests perform
  15. any possible ordering test on two tokens using the ASCII ordering. 
  16. The extended test that caused the trouble Frank reported is the pair
  17.  
  18.         IF = token1 token2              IF EQ token1 token2
  19.  
  20. The second form is quite unambiguous and reliable.  The first form,
  21. however, can get confused with the older equality test using the
  22. syntax
  23.  
  24.         IF string1=string2
  25.  
  26. The latter form requires that there be no spaces between the strings
  27. and the equal sign, so that the entire expression will appear as a
  28. single token (group of characters without intervening spaces).  The
  29. trouble arises when the first token is null (no characters at all). 
  30. Then the test expression looks like
  31.  
  32.         IF =string2
  33.  
  34. To avoid confusion with the extended syntax, Z33IF10 looks for the
  35. equal sign beginning in the second character position of the first
  36. token in the command tail.  With the null string1, the parser does not
  37. recognize the expression as the old equality syntax and treats the
  38. expression "=string2" as a condition and looks up the first two
  39. characters, the equal sign with the first character of the operand, in
  40. the condition table.  Usually it will not find it and will report a
  41. "bad condition" error (if by chance it is recognized, things may be
  42. even worse).
  43.  
  44. There are a number of ways to deal with this difficulty.  Frank
  45. suggested a perfectly good one: put the non-parameter token in the
  46. first position and the parameter in the second.  Another similar
  47. approach (one that I have to take on my IBM 3081 mainframe, which is
  48. incredibly dumb by micro standards) is to include a fixed character
  49. with each token, as in
  50.  
  51.         IF .$1=.//
  52.  
  53. The trouble with those two solutions is that they are easy to forget. 
  54. Slightly better is to simply and permanently forget the old syntax and
  55. always use the "IF EQ .." form.  That is what I do.  With that there
  56. is no doubt about its working.
  57.  
  58. The real solution, of course, is to make Z33IF smarter.  I am sure
  59. that could be done, but I did not have the energy (or think it was
  60. worth the trouble) to do that, so instead I performed a relatively
  61. quick hack.  I made it possible to set an equate to specifically
  62. exclude "=" from the list of extended tests.  For "GE" you can still
  63. alternatively use ">=" but for equality testing you must use the "EQ"
  64. form.  The equal sign is reserved for the old syntax.  This solution
  65. is implemented in Z33IF11.  I hope this will restore my tarnished
  66. reputation among the ultra-alias hackers!
  67.  
  68.                                                 Jay Sage, 08/31/87
  69.