home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / lang / rexx / 898 < prev    next >
Encoding:
Text File  |  1992-09-07  |  3.4 KB  |  62 lines
  1. Newsgroups: comp.lang.rexx
  2. Path: sparky!uunet!mcsun!sunic!sejnet.sunet.se!eric
  3. From: eric@sejnet.sunet.se (Eric Thomas)
  4. Subject: Re: Blanks, REXX, and portability...
  5. Message-ID: <1992Sep5.134720.1@sejnet.sunet.se>
  6. Lines: 49
  7. Sender: news@sunic.sunet.se
  8. Reply-To: ERIC@SEARN.SUNET.SE
  9. Organization: SUNET, Stockholm, Sweden
  10. References: <9208270054.AA19196@SERVER.uwindsor.ca> <ANDERS.92Aug27063035@lise3.lise.unit.no> <1992Aug27.175521.1@sejnet.sunet.se> <mwm.1pdx@contessa.palo-alto.ca.us>
  11. Date: Sat, 5 Sep 1992 13:47:20 GMT
  12.  
  13. In article <mwm.1pdx@contessa.palo-alto.ca.us>, mwm@contessa.palo-alto.ca.us (Mike Meyer) writes:
  14. > In <1992Aug27.175521.1@sejnet.sunet.se>, eric@sejnet.sunet.se (Eric Thomas) wrote:
  15. >> Ok, time for the usual stupid question. Say I have a program that does:
  16. >> 
  17. >>                   Parse var line ':'tagname'.'value' :'line
  18. >> 
  19. >> Say I run that program on an ASCII system which recognize the 20-odd types of
  20. >> blanks Otto showed in his posting. Where does my 'value' variable end, when the
  21. >> interpreter encounters a SPACE followed by colon (ancient, despicable, evil
  22. >> EBCDIC-type behaviour, surely that must not be the case), or also when it
  23. >> encounters TAB followed by colon (nice, modern ASCII-type behaviour which
  24. >> happens to break the program because that is not what the programmer wanted
  25. >> and thought the interpreter would do).
  26. > 
  27. > What you want it to be is whatever whoever generated the input thought
  28. > it would be.
  29.  
  30. Ah yes, the interpreter uses its divinatory powers to read the mind of whoever
  31. generated the input? Seeing a literal of ' :', it thinks "Aww, this must be one
  32. of these NAMES file IBM thingies, let's stop on a blank only". Seeing ': ', it
  33. thinks "Ah, this is clearly someone parsing a RFC822 header, let's stop on any
  34. white space".
  35.  
  36. > I.e. - I have to accept both space and tab as space, because the
  37. > standards document I'm using _says_ I do.
  38.  
  39. Really? Damn. I have all this mail software in REXX on my VM machine where the
  40. interpreter only stops on blanks, how can I possibly have made it respect the
  41. RFC? It must have cost me thousands of lines of code. Let me check it. Oh, it
  42. looks like all it took was a function call on ONE line out of several thousand,
  43. the one in the loop that reads the incoming header and calls the parser! But to
  44. think I had to key in an extra 30 characters when THE SYSTEM should have known
  45. what I meant to do and done it for me :((((((( I will petition the ANSI REXX
  46. committee to change the language so I never have to do that again!!!!!!
  47.  
  48. Anyway, I understand the issue much better now: we're back to the usual
  49. religious arguments. People like Mike will never accept a solution which they
  50. perceive to be un-unixish. Well as Mike pointed out, I don't really give a damn
  51. since I'm moving away from REXX, but I find this both funny and saddening. REXX
  52. is intrinsically un-unixish: identifiers and statements are not case sensitive,
  53. the language is verbose, very few special characters are used, strings are not
  54. terminated by \0, the default value of a variable is its name in UPPER case,
  55. and so on. REXX has its own personality, and it can never become unixish no
  56. matter how hard you try. So I find it strange that people who want to unixify
  57. REXX even bother, when there are a lot of other unix scripting languages to
  58. choose from. On the other hand, I am not really surprised - the spirit of the
  59. crusades will live forever, I suppose this is human nature.
  60.  
  61.   Eric
  62.