Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!rpi!uupsi!sunic!sejnet.sunet.se!eric
From: eric@sejnet.sunet.se (Eric Thomas, SUNET)
Newsgroups: comp.lang.rexx
Subject: Re:  REXX, VM/CMS
Summary: more drivel about unimportant topics
Message-ID: <2851@sunic.sunet.se>
Date: 25 Jan 91 15:08:18 GMT
References: <1991Jan22.022019.5280@ncsuvx.ncsu.edu> <1991Jan23.135615.20072@lotus.com> <2848@sunic.sunet.se> <1991Jan24.170939.11582@lotus.com>
Sender: news@sunic.sunet.se
Reply-To: eric@sejnet.sunet.se
Organization: Swedish University Network (SUNET), Stockholm, Sweden
Lines: 39
News-Software: VAX/VMS VNEWS 1.3-5

In article <1991Jan24.170939.11582@lotus.com>, patman@lotus.com (Pat Mancuso) writes...
>As EXEC2 has no concept of stem variables (see disclaimer), EXECIO's
>STEM option was set up to cater to both REXX and EXEC2.

While I am not one of the developers of EXECIO (god forbid!) and have not heard
anything from them to back up this statement, I am fairly convinced that this
is not the case. Remember, the STEM option appeared in CMS release 4, and was
not available before. REXX was introduced in CMS release 3, and EXECCOMM was
already there. I believe the STEM option was created specifically for REXX, to
make life easier for the programmers and also to get rid of the 255 bytes
(stack) limitation.

>Yes, you can still use them in REXX as LINE1 and LINE2, but for the cases
>where you *don't* know the number of lines in a data source (such as a list
>of the files on a disk...) a stem seems more appropriate.

I agree, of course. I was just pointing out that there ARE cases, in REXX,
where the use of non-stem variables is ALSO appropriate.

>The overhead
>in accessing line.1 and line.2 over line1 and line2 is minimal (given
>that you know n=2) and considering that someday n might change to 3 (or 37 for
>that matter), the maintenance/code-clarity benefits outweigh it in my
>opinion.

I do not agree. When you write 'line.2', REXX first evaluates the expression
'2', finds out that its value is '2', builds up the resulting variable name,
finds out that it is 'line.2' (really?), and then calls the fetch-that-variable
routine. With 'line2', the routine is called directly. If you use that variable
in a loop, it can make a difference; the overhead for each fetching operation
is an extra 125% or so.

Granted, if 2 changes to 3, you will have to c/line2/line3/* *, but then how
does this differ from having to change all occurences of line.2 to line.3? Or
did you mean something like 'line.parmline'? THAT is cleaner, but also 4 times
slower... It may or may not matter, depending on how often you access the
variable. 

  Eric