home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / lang / rexx / 746 < prev    next >
Encoding:
Text File  |  1992-08-19  |  6.3 KB  |  138 lines
  1. Newsgroups: comp.lang.rexx
  2. Path: sparky!uunet!mcsun!sunic!ugle.unit.no!ugle!anders
  3. From: anders@lise11.lise.unit.no (Anders Christensen)
  4. Subject: Re: Capturing System Command Output (was: SH Backquote)
  5. In-Reply-To: SEB1525@MVS.draper.com's message of Wed, 19 Aug 1992 14:00:00 GMT
  6. Message-ID: <ANDERS.92Aug19231649@lise11.lise.unit.no>
  7. Sender: news@ugle.unit.no (NetNews Administrator)
  8. Organization: /home/flipper/anders/.organization
  9. References: <ANDERS.92Aug18223235@lise8.lise.unit.no>
  10.     <19920819090033SEB1525@MVS.draper.com>
  11. Date: 19 Aug 92 23:16:49
  12. Lines: 124
  13.  
  14. In article <19920819090033SEB1525@MVS.draper.com> SEB1525@MVS.draper.com (Steve Bacher) writes:
  15.  
  16. > In article <ANDERS.92Aug18223235@lise8.lise.unit.no>,
  17. > anders@lise8.lise.unit.no (Anders Christensen) writes:
  18.  
  19. > >The three different _conceptual_ methods that I am aware of are
  20. > [following very abbreviated]
  21. > >
  22. > >      files = 'ls'(directory)
  23. > >      'ls' directory ' >LIFO'     /* or "|rxstack" */
  24. > >       'ls | rxstack'
  25. > >      rcode = popen( "ls" directory,, "ls-output" )
  26. > 
  27. > Er, our *four* different conceptual methods...?
  28.  
  29. No, three. _For_the_user_ it is three different conceptual methods,
  30. since both ">LIFO" and "|rxstack" is the same Rexx programming
  31. concepts. The concepts of implementation, well that is a completely
  32. different thing.
  33.  
  34. I'd like this debate to differ between the concepts of Rexx
  35. programming, and concepts of implementation. It is important to design
  36. a good syntax, and _then_ do the implementation, instead of deciding
  37. on an implementation and the design a suitable syntax for it. 
  38.  
  39. In the latter case, you are going to get an syntax ridden with
  40. implementation specific details and lots of special cases. And it will
  41. probably only be really useful to the persons that know the opsys
  42. specific details that the implementation builds on. If the point of
  43. view is: "Wouldn't it be nice if feature XXX of opsys YYY would be
  44. available in Rexx?" You are guaranteed to get: 1) unportable Rexx
  45. implementations; 2) unportable Rexx scripts; 3) 'unportable' Rexx
  46. users (knowing Rexx is not enough to move to another platform, you
  47. have to know the features of the operating system too).
  48.  
  49. Therefore, can we discuss a _syntax_ first, and try to keep concepts
  50. of how to _implement_ that syntax away until we have evaluated how
  51. good the various syntaxes are, and we need to know how implementable
  52. they are?
  53.  
  54. > Just from the UI POV, how about a fifth:
  55. >
  56. >      rcode = queue_to_stack("ls" directory)
  57.  
  58. OK, this very well illustrates the the main conceptual question, which
  59. is : COMMANDS vs FUNCTIONS.
  60.  
  61. The '>LIFO' and '|rxstack' methods are COMMAND-driven, all the other 
  62. are FUNCTION-driven. I'd like to see a good command-driven interface.
  63. And why? Because the concept of "anything not a keywords falls through
  64. to the outer environment" is just so elegant. A rexx program is
  65. basically just a list of commands to an environment. And then you can
  66. add Rexx keywords to create a structure in those commands. That is the
  67. the magic of Rexx: The structure of a programming language to be added
  68. on top of an unintelligent command interpreter. 
  69.  
  70. On the other hand, in a function-driven based approach, the commands
  71. are put _into_ the Rexx language, as parameters to Rexx functions. I
  72. think that is far less elegant, and (more important) I think that the
  73. resulting code and structure is far less obvious.
  74.  
  75. > Similar syntactically to popen(), but captures stdout and puts it
  76. > on the data stack or in stem variables a la EXECIO.
  77.  
  78. There are three different approaches: 1) put it on the stack; 2) put
  79. it into variables; and 3) let it be an expression. All of them have
  80. weeknesses and strengths, so perhaps all three should be possible to
  81. do. But what _syntax_ to use for each single method?
  82.  
  83. > And what about stderr?  Maybe an optional third argument could
  84. > specify the destination for stderr.  (Let's not get fancy and
  85. > start specifying destinations for file descriptor numbers...)
  86.  
  87. Well, 'stderr' is a Unix-concept. If the starting point is "how to
  88. handle stderr", we'll end up with a system tailored for Unix. I'd
  89. rather pose the question like: what about other I/O streams than
  90. standard input and standard output. Other opsys'es (e.g. like VMS)
  91. have more I/O streams, even more than Unix' three.
  92.  
  93. > I don't like the ">LIFO" syntax because that conflicts with a
  94. > valid file-redirection spec, using up potential file names in
  95. > a magic-cookie sort of way. 
  96.  
  97. I don't like it either, but for another reason. It might fool users
  98. who know about redirection into believing that this is some sort of
  99. redirection.  If someone has a better notation for it, please tell me!
  100.  
  101. >                              Also, this and the piping and popen
  102. > solutions are too Unix-oriented in coding style; the programming
  103. > interface to get at the data should be in the REXX culture, not
  104. > the culture of the surrounding OS.  This would also get around
  105. > the "address something-other-than-the-native-shell" problem
  106. > you alluded to with the 'address ftp; "ls | rxqueue"' difficulty.
  107.  
  108. Yes!!! Exactly!
  109.  
  110. However, there _are_ no REXX culture on how to 'move' information from
  111. the outer environment into the rexx interpreter. TRL avoids the
  112. problem, assuming that the environment itself knows how to put things
  113. on the stack, or otherwise communicate with the interpreter. There is
  114. an IBM culture that use the stack heavily, and there are non-IBM
  115. cultures that use linein/lineout/etc heavily. But there is no One Way. 
  116.  
  117. > [speculation on how to implement deleted]
  118.  
  119. Shall we start by trying to find a good syntax? Intuitive, clear,
  120. userfriendly (yuk, that's a buzz-word!), conceptual clean, etc, etc?
  121.  
  122. > >A better solution might be to label the _methods_ rather than the
  123. > >_interpreters_, then it would be possible to check whether an
  124. > >interpreter supports e.g. the popen-based method. Then the user don't
  125. > >have to update his rexxscripts to support new interpreters, but new
  126. > >interpreters will support the already existing methods.
  127.  
  128. > No, a better solution would be to have one method.  Dispatching on
  129. > whether a particular syntax is used is just as bad as, and possibly
  130. > worse than, dispatching on a particular implememntation.
  131.  
  132. I don't feel convinced that we will find One method. At best, we might
  133. arm a function with enough parameters and options to cover all
  134. situations. But I don't think a battleship-sized function would be the
  135. best solution.
  136.  
  137. -anders
  138.