home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / lang / rexx / 891 < prev    next >
Encoding:
Internet Message Format  |  1992-09-07  |  2.7 KB
  1. Path: sparky!uunet!decwrl!contessa!mwm
  2. From: mwm@contessa.palo-alto.ca.us (Mike Meyer)
  3. Subject: Re: Blanks, REXX, and portability...
  4. Newsgroups: comp.lang.rexx
  5. Distribution: world
  6. References: <REXXLIST%92082621432914@DEARN>
  7. X-NewsSoftware: Amiga Yarn 3.4, 1992/08/12 15:49:52
  8. Keywords: 
  9. Summary: 
  10. Message-ID: <mwm.1p79@contessa.palo-alto.ca.us>
  11. Date: 29 Aug 92 23:07:05 PST
  12. Organization: Missionaria Phonibalonica
  13. Lines: 49
  14.  
  15. A question for all of you using EBCDIC who don't think that arbitrary
  16. whitespace should be allowed to seperate words: Why do you care?
  17.  
  18. The only argument I've seen is that allowing input data with tabs
  19. makes programs less portable. This is false. It makes programs more
  20. portable; it makes _data_ less portable.
  21.  
  22. If you think that tabs are evil, you may be right. It doesn't matter.
  23. TAB is an ASCII character that it is perceived of as a long blank, and
  24. people use it as such on a regular basis. Wishing and language
  25. definitions won't make the problem go away; they'll just fail to
  26. generate horses and create headaches for people who want to use the
  27. language.
  28.  
  29. A similar problem shows up in the ANSI C standard. It has this idiotic
  30. restriction that external identifiers must be unique in the first six
  31. characters, case insensitive. I don't know of _anybody_ who liked
  32. this, but there was a very popular system which had a standard linker
  33. with that antiquated restriction. Removing this brain-dead restriction
  34. meant that you couldn't write an ANSI C compiler for that system,
  35. which was considered a bad thing - so the restriction stayed in.
  36.  
  37. While requiring that only space can be treated as a blank character
  38. won't prevent people from implemeting "standard Rexx" on any
  39. particular machine, it will make Rexx hard to use, and cause people to
  40. look to other tools.
  41.  
  42. In <REXXLIST%92082621432914@DEARN>, Otto Stolz <RZOTTO@DKNKURZ1.BITNET> wrote:
  43. > 5. that standard-conforming implementations be required to implement
  44. >    the recognition of white space in a way conforming
  45. >    - to all possible sources for REXX source programs,
  46. >    - to all possible sources for input to REXX programs
  47. >    (cf. note 1);
  48.  
  49. I like that - that means you have to consider every computer system in
  50. the world as a possible source, including all possible character set
  51. mappings in getting the data from there to here. Not to mention all
  52. tapes/decks/etc. that still exists, even if there are no functioning
  53. computers of the type that created them.
  54.  
  55. > In a nutshell: REXX language features should be as permissive as
  56. >                possible when accepting white space, and as predictable
  57. >                as possible when generating it.
  58.  
  59. "Accept permissively and generate strictly" is a good general
  60. guideline whenever portability or interoperability becomes a
  61. consideration.
  62.  
  63.     <mike
  64.