home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / lang / rexx / 1025 < prev    next >
Encoding:
Internet Message Format  |  1992-09-15  |  2.4 KB
  1. Path: sparky!uunet!gatech!psuvax1!psuvm!lrl
  2. Organization: Penn State University
  3. Date: Tue, 15 Sep 1992 15:43:28 EDT
  4. From: Linda Littleton <LRL@psuvm.psu.edu>
  5. Message-ID: <92259.154328LRL@psuvm.psu.edu>
  6. Newsgroups: comp.lang.rexx
  7. Subject: Re: Blanks, REXX, and portability...
  8. References:  <REXXLIST%92090916473059@DEARN>
  9. Lines: 45
  10.  
  11. Whew!  I finally finished wading through this long discussion, and
  12. since I attended the ANSI meeting last week, I thought I'd chime in
  13. with what got discussed there.
  14.  
  15. The topic came up the afternoon of the first day and consumed the
  16. better part of that afternoon.  One group member read a few quotes
  17. of postings from comp.lang.rexx.  The discussion here definitely
  18. had its influence.
  19.  
  20. There was unanimous agreement that tabs (and other white space
  21. characters) need to be acceptable in Rexx source and that tabs
  22. in literal strings should be considered as tabs only.
  23.  
  24. For tabs in data, the programmer would have the ability to specify
  25. whether or not tabs should be translated to spaces.  So, even within
  26. the same program, the programmer could sometimes have tabs translated
  27. and sometimes not.
  28.  
  29. The programmer would specify either "do translations" or "do not do
  30. translations" (syntax for specifying still needs to be discussed).
  31. The leaning for a default was toward doing the translations; however,
  32. I'm having second thoughts on this, thinking that it would be better
  33. for the default to be the current method -- no translations.
  34.  
  35. The interpretation of "do translations" (i.e. which characters get
  36. translated to space) might vary from implementation to implementation
  37. according to what is commonly accepted on that system.  In the first
  38. standard, if the programmer specifies that translation is to be done,
  39. then it gets done however that implementation does it.  In a later
  40. standard (when non-essential enhancements will be added), the user would
  41. be able to specify exactly which characters get translated.
  42.  
  43. We discussed the possibility of having each installation specify which
  44. characters get translated, but decided that it's not good to have the
  45. same implementation work different ways at different installations.
  46.  
  47. As I mentioned, the syntax is not determined, but it would be a one-time-
  48. per-program thing, rather than an extra parameter on each applicable
  49. function call, as someone suggested.
  50.  
  51. Keep your comments coming.  Even though the volume can be overwhelming,
  52. the folks at ANSI want to hear what you're saying and the message is
  53. getting through.
  54.  
  55. -Linda
  56.