home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / lang / rexx / 813 < prev    next >
Encoding:
Text File  |  1992-08-27  |  3.2 KB  |  68 lines
  1. Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
  2. Path: sparky!uunet!paladin.american.edu!auvm!SERVER.UWINDSOR.CA!OPHOF
  3. X-Mailer: ELM [version 2.3 PL11]
  4. Message-ID: <9208280337.AA23023@SERVER.uwindsor.ca>
  5. Newsgroups: comp.lang.rexx
  6. Date:         Thu, 27 Aug 1992 23:37:20 EDT
  7. Sender:       REXX Programming discussion list <REXXLIST@UGA.BITNET>
  8. From:         Scott Ophof <ophof@SERVER.UWINDSOR.CA>
  9. Subject:      Re: Blanks, REXX, and portability...
  10. Comments: To: REXXLIST@uga.cc.uga.edu
  11. In-Reply-To:  <9208271617.AA07011@SERVER.uwindsor.ca>; from "Eric Thomas" at
  12.               Aug 27, 92 5:55 pm
  13. Lines: 53
  14.  
  15. On Thu, 27 Aug 1992 17:55:21 GMT Eric Thomas said:
  16. >In article <ANDERS.92Aug27063035@lise3.lise.unit.no>, anders@lise3.lise.unit.no
  17. >(Anders Christensen) writes:
  18. >> When taking from an ASCII to an EBCDIC system (or vice versa), you
  19. >> _must_ translate the contents. The clue it that *you* don't parse on
  20. >>...
  21. >Ok, time for the usual stupid question. Say I have a program that does:
  22. >                  Parse var line ':'tagname'.'value' :'line
  23.  
  24. >Say I run that program on an ASCII system which recognize the 20-odd types of
  25. >blanks Otto showed in his posting. Where does my 'value' variable end, when the
  26. >interpreter encounters a SPACE followed by colon (ancient, despicable, evil
  27. >EBCDIC-type behaviour, surely that must not be the case), or also when it
  28. >encounters TAB followed by colon (nice, modern ASCII-type behaviour which
  29. >happens to break the program because that is not what the programmer wanted
  30. >and thought the interpreter would do).
  31.  
  32. >In either case you have a problem. If the blank in the search string only
  33. >stands for SPACE, it is very difficult to indicate that you want any of the 20+
  34. >white space characters to match. You would almost need a new WSPARSE command,
  35. >and WSPOS, and so on. If on the other hand the blank stands for any white space
  36. >character, you have no way in the language to halt on just a SPACE when you
  37. >need to do that. OPTIONS is not a solution, a given program may well need both
  38. >functions very often and switching OPTIONS statements is at best impractical.
  39.  
  40. I just tried to set up the required subroutine for a number of
  41. scenarios with the above PARSE statement, the two which Eric
  42. mentions among them.  What a can of worms!  :-(
  43. The only decent solution I can come up with that would work ANYWHERE
  44. is to require each pair of "tagname"/"value" to be on a separate
  45. line (or record, whatever) starting past column 1, with the initial
  46. pair of an entry starting AT col 1. So the first colon on a line
  47. triggers "tagname", period.  And the first dot after it will trigger
  48. "value".  Any forms of leading whitespace on non-initial pairs will
  49. then be ignored, EFFECTIVELY SIDE-STEPPING THE PROBLEM...
  50.  
  51. Of course, the PARSE statement would then be:
  52.    Parse var line ':'tagname'.'value
  53.  
  54. Please read the next para in cynical or serious mode, or a mixture;
  55. both are applicable.  (*grin*)
  56.  
  57. That the file now needs to be restructured isn't really important.
  58. Same re it possibly becoming a mega-line file; on a record-based
  59. machine more disk space will be eaten, especially if fixed-length.
  60. With variable-length records, or on a byte-stream architecture, the
  61. difference shouldn't prove disastrous.
  62.  
  63. BUT this is NO solution to the REAL problem.  HELP!  :-(
  64.  
  65.  
  66. Regards.
  67. $$/
  68.