HDTenEightyP/NetNews huggingface dataset:
From: anders@lise1.lise.unit.no (Anders Christensen)
Subject: Re: Reading inline "code" as input?
Organization: University of Trondheim, Norway
Date: 9 Sep 92 14:11:20

In article <1992Sep8.163642.16833@midway.uchicago.edu> sip1@ellis.uchicago.edu (Timothy F. Sipples) writes:

> Is there any way a REXX program can take data input from itself
> (without resorting to QUEUE or PUSH)?

As has already been suggested by others, the solution is to use
SOURCELINE(), although there are some traps. The following program
should work (I think...):

> /* Rexx */
> 
> FromLine = ThisLine() ; /*
> This is the text to be written out
> blah blah blah blah
> event more blah blah 
> This is the fourth line
> */ ToLine = ThisLine()
> 
> if sourceline()=0 then do
>    say 'Error: interpreter does not record source lines'
>    exit 1
>    end
> 
> if sourceline( FromLine ) = '' then do
>    say 'Error: interpreter substitues source lines with nullstrings'
>    exit 2
>    end
> 
> do Count = FromLine+1 to ToLine-1
>    say sourceline( Count ) 
>    end
> 
> exit 0
> 
> ThisLine: return Sigl

The first trap is avoided by enclosing the text to be written out in
comments.  If you don't, there might be some surprises waiting for
you, depending on how the interpreter parses the input. You might
avoid problems by carefully selecting the contents of the text, but it
is far easier to just comment it out.

The next trap is that the definition of SOURCELINE() was relaxed
between first and second edition of TRL. In the second edition, there
are two shortcuts the an implementation might use:

  1) It may ignore SOURCELINE() altogether, and return '0' for any
     call to SOURCELINE() without a parameter. If a parameter is
     supplied to SOURCELINE(), it must be positive, but not greater
     than the result of SOURCELINE() without a parameter (i.e. a whole
     number greater than 0 and less than 1 ... consequently, calling
     SOURCELINE() with a parameter is illegal in this situation).

  2) An implementation might choose to return the nullstring for any
     call to SOURCELINE() with a parameter.

The two if-clauses in the code above tests for these conditions. You
probably want to do something else than exit, though. Btw, the last of
the two if-clauses are not fool-proof, an implementation may choose
itself which lines not to record, so it might have 'FromLine' but not
the text, or vice versa.

Actually, these two shortcuts are probably meant for Rexx compilers,
but I can't see any reason why not any Rexx implementation might use
them, so you should never write code that depends on SOURCELINE().
(Ofcourse, if you are using an implementation that does record the
source lines, and you don't care about portability, you can ignore the
two if-clauses.)

The last trap is to avoid anything resembling a Rexx code optimizer.
These will often strip comments, collapse whitespace, put everyting on
one line, tokenize the code ... all which might make this program do
something else ...

All in all, it is probably better to just make a lot of PUSH clauses
and pull the data from the stack; or initiate a compound variable; or
even use an external datafile. 

-anders
From: kiehl@ibt013.ibt.kfa-juelich.de (Horst Kiehl)
Newsgroups: comp.lang.rexx
Subject: Re: Reading inline "code" as input?
Keywords: inline, sourceline
Date: 9 Sep 92 09:25:07 GMT
Reply-To: kiehl@ibt013.ibt.kfa-juelich.de (Horst Kiehl)
Organization: Forschungszentrum Juelich GmbH (KFA), Germany

In article <1992Sep8.163642.16833@midway.uchicago.edu>,
sip1@ellis.uchicago.edu (Timothy F. Sipples) writes:

>Is there any way a REXX program can take data input from itself
>(without resorting to QUEUE or PUSH)?

>I know I can detect how many lines are in the program -- there's a
>function to do that -- but can I actually read the lines in?

>The reason I am asking is that I am working on enhancements to
>REXXShip, and a nice one would be to incorporate XXEncode
>compatibility, which would mean having an unmodified stretch of bytes
>in the middle of the code for purposes of encoding a binary file.  The
>REXX "wrapper" would read that stretch of bytes and decode the file.

OK, so it's time to give help in the other direction...

From "The REXX Language" (1985 edition though),
Chapter 8, "Built-in Functions":

   SOURCELINE([n])

      If n is ommitted, returns the line number of the final line in the program.

      If n is given, the nth line in the program is returned. n must be a positive whole
      number, and must not exceed the numbr of the final line in the program.

So you could insert the XXEncoded stuff in a comment in the middle
of the program, like:

   /* XX:
   SDFJKGSASD
   ASDFJASDLD
   ASDFLASDFL
   ASDFL
   */

and locate the line containing ' XX:' by a loop using SOURCELINE.

But it is "cleaner" to use an internal subroutine call instead of SIGNAL
(which is for exception purposes only), like:

   /* REXXShip */

   call decode_contents

   exit

   /* XX:
   SDFJKGSASD
   ASDFJASDLD
   ASDFLASDFL
   ASDFL
   */

   decode_contents:

      do i= 1 to sourceline() until pos(' XX:', sourceline(i)) \== 0
      end

      /* Here, I's value is either the number of the first line with XX-code */
      /*                    or greater than SOURCELINE()                     */

      if i >> sourceline() then

         say 'Error'

      else do

         /* Decode */

      end  

   return

I hope (well, I'm quite sure) :-) this helps.

All the best,

Horst
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
X-Delivery-Notice:  SMTP MAIL FROM does not correspond to sender.
X-Mts: smtp
Newsgroups: comp.lang.rexx
Date:         Tue, 8 Sep 1992 13:50:26 -0400
From:         cultural elite <dsr@LNS598.TN.CORNELL.EDU>
Subject:      Re: Blanks, REXX, and portability...
Comments: To: General REXX Language Discussion List
              <REXXLIST@ucf1vm.cc.ucf.edu>

Dave Gomberg <GOMBERG@UCSFVM.BITNET> writes:
>On Tue, 8 Sep 1992 12:32:48 -0400 cultural elite said:
>>Ok, call me blind, I but I can't see this hole I seem to be in.  You'll
>>have to explain how you get c=a||b; pos(a,c)=0 out of any sensible
>>proposal.
>
>If the synonymy of tabs to a particular number of blanks were accepted, and
>if assignment did normalization (as it often does, both in standards and in
>practice) then c might well have a tab when a ended and b began with strings
>of blanks.   Dave

Wild.  What languages have you used that do normalization on assignment?
It doesn't sound to me like a reasonable thing to do.

But anyway, I'm not advocating that tabs and blanks be made generally
synonymous--all I want is for them to both be accepted as word separators
in parse, word(), words(), and a few other obvious places, which does not
imply general synonymy.  However, Eric may have come up with a serious
objection with his argument that this implies '\t' = ' ' be true, which
I'm not entirely happy about.
--
Dan Riley                          Internet:   dsr@lns598.tn.cornell.edu
Wilson Lab, Cornell University     HEPNET/SPAN: lns598::dsr (44630::dsr)
	 "Maybe, leastways is the best way of all" -Caterwaul
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: comp.lang.rexx
Date:         Sun, 6 Sep 1992 17:47:49 PDT
From:         Dave Gomberg <GOMBERG@UCSFVM.BITNET>
Subject:      Re: Blanks, REXX, and portability...
              1 Sep 1992 05:25:50 GMT from <mwm@CONTESSA.PALO-ALTO.CA.US>

I have been deeply involved with ASCII since many of you were in diapers
(1960).   And I suspect I have read at least the earlier standards
much oftener than most of you have.  And the purpose of HT or FF is not
printer driving (the printers for which ASCII was defined originally
supported neither of those characters).  So let's not confuse the issue.
Two is not twenty.  Anyone who thinks the function of a character set
is to drive composition devices needs to go back to school and learn
what a character set is and how to drive a composition device.  And G*d
help us all if we are forced to use a character set designed with that
little knowledge and intelligence.   Dave
From: eric@sejnet.sunet.se (Eric Thomas)
Newsgroups: comp.lang.rexx
Subject: Re: Blanks, REXX, and portability...
Date: 8 Sep 92 15:26:10 GMT
Reply-To: ERIC@SEARN.SUNET.SE
Organization: SUNET, Stockholm, Sweden

In article <MARTINC.92Sep7194107@grover.cs.unc.edu>, martinc@grover.cs.unc.edu (Charles R. Martin) writes:
> I don't think this (rather dippy) analogy holds very well.  If parse
> were extended with a regular expression syntax that was a strict
> extension -- that is, any program which didn't use the reg exp syntax to
> get results isn't broken by the addition -- then we'd know that (a) you
> can do anything you did before, and (b) that you could do neat new
> things.  It's like if someone started making screwdrivers out of a
> material with a very high yield point, so that even if you were prying
> up a trap door with an elephant on it the shaft would return to shape:
> no one would notice that they were any different, except when they tried
> to use them as prybars.

And when they saw the price on the cash register. Your analogy doesn't hold,
it's not like if someone started making these super-screwdrivers, it's like if
a new law required that all screwdrivers be made this way. If you want to make
your own 'REXXrg' language for your private use, I really have no objection.
You *were* talking about changing the standard, weren't you?

  Eric
Organization: Penn State University
Date: Tue, 15 Sep 1992 15:46:48 EDT
From: Linda Littleton <LRL@psuvm.psu.edu>
Newsgroups: comp.lang.rexx
Subject: Re: ARG() behaviour

In article <9209142023.AA09198@SERVER.uwindsor.ca>, Scott Ophof
<ophof@SERVER.UWINDSOR.CA> says:

>The ARG() function behaves differently in different implementations
>and levels.
>The following returns either 4, 5, or 6, depending on the opsys.

>   Trace OFF
>     Say Function('The number', 'of',, 'argstrings',,)
>     Exit
>   Function:  Procedure
>     Return arg

This was discussed briefly at the ANSI meeting and it was acknowledged
that implementations differ on this.  MFC had strong reasons why the
answer should be 4; others had strong (umm) arguments why it should
be 6.  I don't remember anyone arguing for 5 and sorry, I don't remember
the reasoning.

It feels right to me that the answer should be 6; otherwise the programmer
wouldn't have added the extra commas.  Does anyone have a particular need
for this to be one way or the other?
Newsgroups: comp.lang.rexx
From: SEB1525@MVS.draper.com (Steve Bacher)
Subject: User Defined Word Delimiters (was Blanks, REXX, and          portability...)
Organization: Draper Laboratory
Date: Sat, 12 Sep 1992 22:34:00 GMT

In article <1992Sep11.190834.16887@hou.amoco.com>,
zjlc12@hou.amoco.com (Jerry Campbell) proposes:

>To summarize:
>
>    1 - a word delimiter is not just a blank space, it can be anything, given
>        the further following qualifications.
>    2 - each interpreter implementor may choose to select a set of default
>        delimiter characters (that may be thought of as whitespace).
>    3 - each word oriented, builtin function will have an extra parameter that
>        can be used to override the implementation default.
>    4 - logical comparisons will use the implementation default delimiters to
>        fudge the ends of strings.  Unless the strict comparator operators are
>        used.

(I have problems with (4), but I'll let them go for now.)

One winning feature of this proposal is that the programmer would be
able to divide a string into a words that are not blank-separated.

For example, one could get a list of words delimited by ":" or "|", as
are so popular in Un*x system files, through use of the WORDS and WORD
BIF's.  This would make REXX more competitive with awk's split and
perl's whatever-unreadable-mess functions.

One could also populate a string with random character goo via the
SPACE BIF.  The possibilities are endless.

--
Steve Bacher (Batchman)                 Draper Laboratory
Internet: seb@draper.com                Cambridge, MA, USA
Newsgroups: comp.lang.rexx
From: LRL@psuvm.psu.edu (Linda Littleton)
Newsgroups: comp.lang.rexx
Subject: ANSI schedule
Date: 15 Sep 92 20:25:44 GMT
Expires: 12/9/92
Organization: Penn State University

Here is the meeting schedule for future ANSI meetings.  Those of you
on the west coast should think about coming to the December meeting.
I can send you meeting details if you're interested.

   Meeting 7     Dec 7-9   1992   Berkeley
   Meeting 8     Mar 24-26 1993   Columbia, MD  (near Baltimore)
   Meeting 9     May 21-23 1993   San Diego (adjacent to Rexx Symposium)
   Meeting 10    Sep 15-17 1993   Chicago
   Meeting 11    Early Dec 1993   possibly Orlando

Any of you who want to become an "interested party", so that you
receive all of the official mailings, should contact:

   Neil Milsted - nfnm@wrkgrp.com
   iX Corporation
   575 W. Madison #3610
   Chicago, IL  60606
   312 902 2149
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Subject: (no subject given)
Newsgroups: comp.lang.rexx
Date:         Mon, 14 Sep 1992 06:33:15 PDT
From:         Dave Gomberg <GOMBERG@UCSFVM.BITNET>
              14 Sep 1992 14:59:51 DST from <VALOREV@DKIBMVM1.VNET.IBM.COM>

On Mon, 14 Sep 1992 14:59:51 DST <VALOREV@DKIBMVM1.VNET.IBM.COM> said:
>And while you are at it, why don't you also leave out the 'BY 1' since
>thise is the default ?

I debated whether to mention the BY 1 or not.  It is there for PL1
compatibility (I used to write a lot of PL1).  In PL1, DO I=1; means
the same as DO I=1 TO 1; so you really need the BY 1.  Of course, in
REXX it is optional, but it does reinforce the idea that we wish to
step thru I values without limit (while TO something just implies that
there is this magic value something that is our upper limit).  Good
point.   Dave
From: bobcook@unixhub.SLAC.Stanford.EDU (Bob Cook)
Newsgroups: comp.lang.rexx
Subject: Re: NOVALUE (was: Blanks, REXX, and portability...)
Date: 15 Sep 92 02:01:30 GMT
Reply-To: bobcook@unixhub.SLAC.Stanford.EDU (Bob Cook)

Dave Gomberg writes
>On Sat, 12 Sep 1992 01:18:34 GMT Bob Cook said:
>>That is exactly the point that I'm commenting upon.  I have been bitten by
>>introducing a hard-to-find bug because a reference to "a.x", where x was  
meant
>>to be a variable, instead treated the x as a constant because the variable x
>>had (mistakenly) never had a value assigned.
>
>Wait, if you intended to have x have the value 123 but by mistake it was
>undefined, then are you saying that just by lucky accident a.x WAS defined?
>That streches my credulity some.

Would your credulity shrink back to normal if the code started with
"a. = whatever"?

--
Bob Cook                              bobcook@slac.stanford.edu
Stanford Linear Accelerator Center    NeXT mail okay
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: comp.lang.rexx
Date:         Sun, 13 Sep 1992 20:42:48 PDT
From:         Dave Gomberg <GOMBERG@UCSFVM.BITNET>
Subject:      Re: new rexx programmer
              14 Sep 1992 01:06:19 GMT from <martinc@GROVER.CS.UNC.EDU>

On Mon, 14 Sep 1992 01:06:19 GMT Charles R. Martin said:
>	do ix=1 to umpteen while line <> ''
>	   parse ...
>	end

Actually, the "right" code in this situation is:

do ix=1 by 1 while line<>''

There is no requirement in the language to specify an upper limit, and
since in this case it would just be arbitrary, leave it out.   It also
shows that you are expecting an empty line, and not umpteen, to stop
the loop.  Yours in REXX.   Dave G.  (Watch for "REXX for OS/2" from
Monarch Publishing soon, I hope!)
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
X-Mailer: ELM [version 2.3 PL11]
Newsgroups: comp.lang.rexx
Date:         Tue, 15 Sep 1992 01:25:21 EDT
From:         Scott Ophof <ophof@SERVER.UWINDSOR.CA>
Subject:      Relaxing of argument-passing restriction?
Comments: To: REXX Discussion list <REXXLIST@uga.cc.uga.edu>

A definite improvement of REXX would be to define the number of
passable argument strings AT THE COMMAND-LINE LEVEL to be
implementation-dependant.  Calls to internal subroutines & built-in
functions are not subject to this limit.

I'm referring to the dropping of the following on page 83 of "The
REXX Language" (edition 2):
   3:  Programs called as commands can only have 0 or 1 argument
       strings.
and (getting way ahead) replacing it with something like:
   3:  Though implementation-dependant, programs called as commands
       will usually have 0 or 1 argument strings.

This restriction has always been a problem in building really good
stuff in REXX.
Who can come up with really valid reasons for having this max of 1
apply to programs called as commands?  And/or other reasons PRO
relaxation of the restriction?


Regards.
$$/
From: imc@comlab.ox.ac.uk (Ian Collier)
Newsgroups: comp.lang.rexx
Subject: Re: Reading inline "code" as input?
Keywords: inline, sourceline
Date: 9 Sep 92 14:08:27 GMT
Organization: Oxford University Computing Laboratory, UK
X-Local-Date: Wednesday, 9th September 1992 at 3:08pm BST
Originator: imc@msc11.comlab

In article <275@zam103.zam.kfa-juelich.de>, kiehl@ibt013.ibt.kfa-juelich.de (Horst Kiehl) wrote:
>In article <1992Sep8.163642.16833@midway.uchicago.edu>,
>sip1@ellis.uchicago.edu (Timothy F. Sipples) writes:

>>Is there any way a REXX program can take data input from itself
>>(without resorting to QUEUE or PUSH)?

>So you could insert the XXEncoded stuff in a comment in the middle
>of the program, [...]
>and locate the line containing ' XX:' by a loop using SOURCELINE.

Two points:
 (a) You don't necessarily need to locate the XX: - use something like this:

        print_data: signal data_end  /*
        A line of data
        Another line of data
        ...
        The last line of data
        */
        data_end: do i = sigl to sourceline()
           data = sourceline(i)
           if data == "*/" then leave
           ... do whatever with data ...
        end
        return

     The point I'm making is that it's possible to have Rexx tell you the
     line number of the data by using the special variable "sigl".  I
     wouldn't consider this use of signal to be at all untidy or
     unnecessary.

 (b) Someone has already mentioned that unmatched quotes and comment
     delimiters in the data may cause problems.  Well if the data is all
     typed in hex (or if XXencode data doesn't contain those characters
     anyway), you can easily avoid that problem.  Simply use the x2c()
     conversion function on each line before dealing with it.

Ian Collier
Ian.Collier@prg.ox.ac.uk | imc@ecs.ox.ac.uk
From: mwm@contessa.palo-alto.ca.us (Mike Meyer)
Subject: Re: Blanks, REXX, and portability...
Newsgroups: comp.lang.rexx
Distribution: world
X-NewsSoftware: Amiga Yarn 3.4, 1992/08/12 15:49:52
Keywords: 
Summary: 
Date: 30 Aug 92 16:35:41 PST
Organization: Missionaria Phonibalonica

In <1992Aug27.175521.1@sejnet.sunet.se>, eric@sejnet.sunet.se (Eric Thomas) wrote:
> Ok, time for the usual stupid question. Say I have a program that does:
> 
>                   Parse var line ':'tagname'.'value' :'line
> 
> Say I run that program on an ASCII system which recognize the 20-odd types of
> blanks Otto showed in his posting. Where does my 'value' variable end, when the
> interpreter encounters a SPACE followed by colon (ancient, despicable, evil
> EBCDIC-type behaviour, surely that must not be the case), or also when it
> encounters TAB followed by colon (nice, modern ASCII-type behaviour which
> happens to break the program because that is not what the programmer wanted
> and thought the interpreter would do).

What you want it to be is whatever whoever generated the input thought
it would be. In the case that I run into most, that's easy.  I'm
dealing with data that follows Internet Request For Comment #822,
which says:

     3.4.2.  WHITE SPACE

        Note:  In structured field bodies, multiple linear space ASCII
               characters  (namely  HTABs  and  SPACEs) are treated as
               single spaces and may freely surround any  symbol.   In
               all header fields, the only place in which at least one
               LWSP-char is REQUIRED is at the beginning of  continua-
               tion lines in a folded field.

I.e. - I have to accept both space and tab as space, because the
standards document I'm using _says_ I do.

> In either case you have a problem. If the blank in the search string only
> stands for SPACE, it is very difficult to indicate that you want any of the 20+
> white space characters to match. You would almost need a new WSPARSE command,
> and WSPOS, and so on. If on the other hand the blank stands for any white space
> character, you have no way in the language to halt on just a SPACE when you
> need to do that. OPTIONS is not a solution, a given program may well need both
> functions very often and switching OPTIONS statements is at best impractical.

How many cases have you run into that need both behaviors (nuts, how
many have you run into other than the one you normally deal with)? The
only ones I've met were that way because the input data stream allowed
used TABs as whitespace, but the output streams didn't. That case
doesn't require changing modes in midstream, it just means you can't
generate TABs. No problem.

	<mike

Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
X-Mailer: ELM [version 2.3 PL11]
Newsgroups: comp.lang.rexx
Date:         Tue, 15 Sep 1992 15:33:20 EDT
From:         Scott Ophof <ophof@SERVER.UWINDSOR.CA>
Subject:      Re: Expressions in compound variables (was Re: NOVALUE)
Comments: To: REXXLIST@uga.cc.uga.edu
              at Sep 14, 92 5:13 pm

On Mon, 14 Sep 1992 17:13:16 EDT Linda Littleton said:
>In article <REXXLIST%92091210585300@UGA.CC.UGA.EDU>, Dave Gomberg says:
>>On Sat, 12 Sep 1992 06:22:02 GMT Paul Gilmartin said:
>>>   say a.(substr('UVWXYZ',4,1))   /* Why not, haven't you wanted it? */
>>it turned out to be next to impossible to define.
>extension and would reduce the "astonishment factor" new users have when
>they find that things like this (especially simpler things like x.(y+1))
>don't work.

We're now 3 years further.  The ANSI-REXX committee might be able to
do what didn't seem possible back then to the SHARE REXX committee?

Like in Linda's example:
   x.(y+1)
currently is a call to the FUNCTION "x."...  How's *that* for an
"astonishment factor"?  (*grin*)
TRL says that a functionname must be a symbol or a literal string.
And the dot is a valid character in a symbol.
Do we need to give up the dot as ending character in a function-
name to achieve this?
May I suggest that we *not* suggest use of "{}} (curly braces) or
"[]" (square brackets)?  That's national language stuff, and thus
even "worse" than the whitespace subject...  (*WINK*)

In REXX as-is, "stem.'LiTeRaL'" is taken as a stem abutted with a
literal (the stem may or may not have been initialised).

   a.x =;    a. =;        (Undefined stem/tail and stem itself)
   Say a.'X'    -->  A.X  (Undefined var abutted with literal)
   a.x = 4;  a. = 0
   Say a.x      -->  0    (Initialised stem, Undefined tail)
   Say a.'X'    -->  0X   (Initialised stem abutted with literal)

The last example here actually was a bit astonishing, till the mush
(No, Al, *not* the mail program!  ;-> ) started bubbling...
The problem is, do we want to give up (part of) the abuttal concept?
In other words (with tongue in cheek), must we type:
   a. || 'o'        -->  Hello  (after setting a.='Hell')
if we want abuttal of the value of a stem and a literal,
and:
   lastname.'John'  -->  Doe
to do what doesn't seem very astonishing but isn't allowed with the
current REXX standard?

These are *some* of the problems we'd run into.  Are there any other
areas which might cause breakage?

As a side note, I wish that there was a file available somewhere
with all the suggestions for enhancements/extensions which did *not*
make it into REXX, with the reasons.  Anyone having an idea could
then determine from that file whether the idea was worth bringing up
(possibly again).  Mike Cowlishaw must have a 3370 disk full of such
suggestions, at 350 items/day when he wrote REXX...


Regards.
$$/