home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / lang / rexx / 870 < prev    next >
Encoding:
Text File  |  1992-09-03  |  3.5 KB  |  86 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: <9209030855.AA17202@SERVER.uwindsor.ca>
  5. Newsgroups: comp.lang.rexx
  6. Date:         Thu, 3 Sep 1992 04:55:26 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:  <9209012046.AA13980@SERVER.uwindsor.ca>; from "Eric Thomas" at
  12.               Sep 1, 92 4:52 pm
  13. Lines: 71
  14.  
  15. On Tue, 1 Sep 1992 16:52:41 GMT Eric Thomas <eric@SEJNET.SUNET.SE> said:
  16. >In article <9208310858.AA28086@SERVER.uwindsor.ca>,         Scott Ophof
  17. ><ophof@SERVER.UWINDSOR.CA> writes:
  18. >> Question:
  19. >> How much breakage would occur if the double quotes retained that
  20. >>...
  21. >>       Parse var data a b . " A("
  22. >> means "ASCII '20'X followed by 'A('".
  23. >>       Parse var data a b . ' A('
  24. >> means "one whitespace followed by 'A('".
  25. >A lot of breakage would occur, I know people who use double quotes all the time
  26. >...
  27.  
  28. Yes, I was already afraid of this, without even considering the
  29. only-one-datatype basic mindset of REXX.  :-(
  30. Maybe it's a failing on my part, but I've never seen a need for more
  31. than one datatype, even when it leads to its own unique astonishment
  32. factor in REXX...  (wry grin)
  33.  
  34.  
  35. >>>A tab in a quoted string is a tab, not a blank, just like in C and other unix
  36. >>>languages.                                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  37. >>  ^^^^^^^^^
  38. >> Are you *100%* *SURE* of this?
  39. >main()
  40. >...
  41. >Prints 9.
  42.  
  43. Your program is a nice way to emulate the C2X() function in C.  :-)
  44. What I meant is the difference between the meaning of single and
  45. double quotes in (at least) the C-shell, which (as I have been
  46. informed) do *not* have identical meanings...  Maybe I shouldn't
  47. have taken the C-shell syntax and conventions as a language?
  48.  
  49.  
  50. >> I claim that with a nice set of functions translating the relevant
  51. >> system commands to a standardised REXX I/O, portability *is* *very*
  52. >> definitely relevant.
  53.  
  54. >Ok Scott, say I give you a unix playstation with a copy of the source code for
  55. >LISTSERV (25-30k lines of REXX), and pay you by the hour to make it work under
  56. >unix. How much money will I save if I give you a REXX interpreter to make the
  57. >conversion easier?
  58.  
  59. Um..  If you were to pay me significantly less "under the table",
  60. you'd have a nice tax shelter...  (hey, I'm joking here!)  :-)
  61.  
  62. >The answer is I'll lose money, because it will take you about 1-2 months to
  63. >realize it is much faster to rewrite everything in C than to try to reuse the
  64. >REXX code with the interpreter.
  65.  
  66. Agreed re existing applications which are heavily based on the
  67. environment they were originally developed in, without real regard
  68. to portability.  Note that this is a *general* statement.
  69.  
  70. Portability in the future seems to depend on creating interfaces
  71. (REXX function packages) that *will* allow the (casual) programmer
  72. to write in a non-opsys-specific manner.  Whitespace/blank/space is
  73. just one of the things that need to be resolved in such a way that
  74. the chance of portability is increased as much as possible.
  75. And I don't think I need to add anything to Ed's 4 points why the
  76. point of portability *is* important.
  77.  
  78. As to the whitespace/blank/space issue (and the likes), are there
  79. any points which haven't been mentioned, but (may) need to be
  80. considered in the light of *portability*?  Like other character
  81. (classes)?
  82.  
  83.  
  84. Regards.
  85. $$/
  86.