From: anders@lise4.lise.unit.no (Anders Christensen)
Subject: Re: PARSE wishlist/brainstorming
Organization: /home/flipper/anders/.organization
Date: 21 Aug 92 00:32:53

In article <1992Aug20.154822.8057@hou.amoco.com> zjlc12@hou.amoco.com (Jerry Campbell) writes:

> Why not add the STEM keyword to the Parse instruction?  
> [...] Let me try an	
> example:

>    data = "Hello world, hello solar sytem, hello galaxy"
>    Parse Var data STEM  "hello" 1 stem. +3

What if the data by accident should contain a comma? What you really
need if you want to do this, is a way to store multiple string in one
variable. Something like:

   data = "hello world", "hello solar system", "hello galaxy"

That is, the comma becomes an sort of operator to be used in
expressions, and it separates between individual strings in that
expression. It would have higher priority than any other operator,
except for parentheses.  It would have some consistency with comma
used to separate parameters in function calls and in PARSE ARG.

But unfortunately, it will open a need for accessing individual
strings in a variable, and you would have to add a lot more syntax
than just the comma-operator. You would need a whole new set of
concepts to deal with variables. It would solve some problems, like
how to fit multiple lines of output into one single variable.  It may
be an interesting thought, but I don't think it would fit easily into
Rexx, and I suspect that it would create more problems than it would
solve :-(

> Another possible new feature that could make use of the STEM idea would be a
> new source keyword, such as QUEUE.  QUEUE would imply "Parse Pull" and keep
> on pulling till the repetition implied in the stem template is
> satisfied or end of stack is reached.  Example:

>    Address "uni-shell" "ls -l" "TO QUEUE"
>    Parse QUEUE STEM 1 permissions. .  user. size. . . . filename.   

Yes, I see. You want the output of 'ls' to go into a stem variable,
but it will not be possible using "ADDRESS 'ls' TO STEM name.", since
you want the various output fields from 'ls' to be stored in various
stems. If the output of 'ls' could be flushed to the stack, it could
be done like this:

   ADDRESS 'uni-shell' 'ls -l' TO QUEUE
   do i=1 to queued()
      parse pull perm.i . user.i size.i . . . filename.i .
      end

(OK, I need to guard the stack better, but the idea should be clear.)
Btw also files and stems could be used in the same way, instead of the
stack: 

   ADDRESS 'uni-shell' 'ls -l' TO STEM lines.
   do i=1 to lines.0
      parse var lines.i perm.i . user.i size.i . . . filename.i .
      end

   ADDRESS 'uni-shell' 'ls -l' TO STREAM 'cmd'
   do i=1 while lines('cmd')>0
      parse value linein('cmd') with perm.i . user.i size.i . . . filename.i .
      end

One main point in your suggestion is that parse can parse multiple
strings in one operation. Actually, it can do that today. When you
parse multiple arguments in one parse statement, with the statement:

   parse arg first, second, third

Expanding this syntax, you might do something like:

   parse pull line1, line2, line3

To parse the three first lines of the stack into separate patterns.
However, this would only be a shortcut notation for three consequitive
parse pull clauses, and I am not sure _that_ would justify expanding
the standard. 

Your other main point is that the number of strings to parse might be
_variable_ at programming time, and dependant on some situation at run
time, as in your last example. But would not that be easy to do within
the current syntax, by putting the parse within a DO-loop? Surely, the
control mechanisms for looping that are built into the DO clause must
be stronger than what you intend to build into PARSE?

>    Address "uni-shell" "ls" "TO STDIN"
>    Parse STREAM STDIN STEM 1 records. +999 (CR_LF)    

What about:

   address 'uni-shell' 'ls' TO STDIN
   do i=1 while lines()>0
      parse linein record.i

Note that the two last lines don't expand the standard at all. What
_do_ expand the standard is the first line, the ADDRESS clause. I
think better control over how to redirect the input and output when
running commands are the important thing here.

If what you want to do, is to put the output of 'ls' into a stem named
"record.", why not the following syntax?

   ADDRESS 'uni-shell' 'ls' TO STEM records.

-anders