HDTenEightyP/NetNews huggingface dataset:
From: ralph@CS.ARIZONA.EDU ("Ralph Griswold")
Newsgroups: comp.lang.icon
Subject: list scanning/pattern matching
Date: 20 Aug 92 14:13:29 GMT
Distribution: inet
Organization: The Internet

We've looked at this problem off and on for over 20 years, but have
never come up with anything that was really useful.  All we've learned
are the reasons why it is not as good an idea as it appears on the
surface.

Richard is right -- the real problem is that list elements are
not simple.  Think about loops in structures.

Looking at it another way, string scanning derives much of its
usefulness from the simplicity of sequences of characters.

Richard's idea of extending strings to sequences of other atomic
values is interesting and deserves consideration despite the
problems he noted with it.
    
Ralph E. Griswold			ralph@cs.arizona.edu
Department of Computer Science 		 uunet!arizona!ralph
The University of Arizona		602-621-6609 (voice)
Tucson, AZ 85721			602-621-9618   (fax)

Newsgroups: comp.lang.icon
From: goer@ellis.uchicago.edu (Richard L. Goerwitz)
Subject: Re: (1) ICON & OS/2 ? (2) Strings vs. Lists.
Reply-To: goer@midway.uchicago.edu
Organization: University of Chicago Computing Organizations
Distribution: inet
Date: Thu, 20 Aug 1992 02:17:37 GMT

In article <920818.12420265.040650@RMC.CP6> lindsay@rmc.ca writes:

>   A few months ago, there were a few ruminations on this board about
>   processing strings as lists or rather vv.; I'd like to open up and expand
>   the subject again.  Plainly there is a logical parallel between a string and
>   a list,

Perhaps you could define what you mean by "list."  Do you mean a LISPish vec-
tor?  Even in Icon, the list is a much more general type, since it can con-
tain objects of all other types.  Instead of unifying lists and strings, may-
be it might be better to talk about expanding strings to cover all homogenous
linear sequences of certain data types.

But then, of course, we lose a lot of our optimizations, and Icon becomes even
more polymorphic (is that the right word?), since things like scanning will
have to be modified to do many different things, depending on the kind of
string it encounters.

Maybe what might we worth thinking about is whether it might be possible to
develop a list scanning mechanism.  I've thought about this a lot, and I don't
really see an elegant mechanism.  Got any ideas?

-- 

   -Richard L. Goerwitz              goer%midway@uchicago.bitnet
   goer@midway.uchicago.edu          rutgers!oddjob!ellis!goer
Newsgroups: comp.lang.icon
From: gerardo@ferris.cray.com (Gerardo Cisneros)
Subject: Re: list scanning
Organization: Cray Research, Inc.
Distribution: inet
Date: 20 Aug 92 14:27:14 CDT

In article <9208201457.AA12761@mpix10.mpi.kun.nl> janpeter@mpi.kun.nl (Jan Peter de Ruiter) writes:
>Could someone perhaps elaborate on the problems and/or proposed
>solutions in the field of list-pattern-matching? I certainly believe that
>it is a tough nut to crack, but I'm interested in what efforts have been
>made in this field, and why they are not working (..well enough).
>[...]
List pattern matching was implemented in the language CONVERT by Adolfo
Guzman and Harold V. McIntosh more than 25 years ago:

A. Guzman and H.V.McIntosh, "CONVERT", Commun. ACM _9_, 604-615 (1966)

It ran as an interpreter under LISP on the IBM 709 and the AN-FSQ 32.

Cheers,

Gerardo Cisneros
-- 
Dr. Gerardo Cisneros		|Cray Research de M'exico, S.A. de C.V.
gerardo.cisneros@cray.com	|Camino a Sta. Teresa 480-A #302
(+52+5)622-8584 		|14020 Tlalpan, D.F., MEXICO
 Anything I said sound like an opinion? Then it's no one's but my own.
Newsgroups: comp.lang.icon
From: goer@ellis.uchicago.edu (Richard L. Goerwitz)
Subject: Re: list scanning
Reply-To: goer@midway.uchicago.edu
Organization: University of Chicago Computing Organizations
Distribution: inet
Date: Fri, 21 Aug 1992 04:51:43 GMT

gerardo@ferris.cray.com (Gerardo Cisneros) writes:
>
>List pattern matching was implemented in the language CONVERT by Adolfo
>Guzman and Harold V. McIntosh more than 25 years ago:
>A. Guzman and H.V.McIntosh, "CONVERT", Commun. ACM _9_, 604-615 (1966)
>It ran as an interpreter under LISP on the IBM 709 and the AN-FSQ 32.

If it's not too much of an imposition, could you perhaps summarize
the salient points, and (if you every actually used this system) how
it "looked and felt"?

-- 

   -Richard L. Goerwitz              goer%midway@uchicago.bitnet
   goer@midway.uchicago.edu          rutgers!oddjob!ellis!goer
From: ralph@CS.ARIZONA.EDU ("Ralph Griswold")
Newsgroups: comp.lang.icon
Subject: Version 8.7 Icon for UNIX and VMS
Date: 17 Aug 92 16:30:01 GMT
Distribution: inet
Organization: The Internet

Version 8.7 of Icon is now available for UNIX and VMS. These implementations
include X Window System features and both the interpreter and the optimizing
compiler. The VMS distribution includes executables.

Complete systems, including source code and the Icon program library, are
available by anonymous FTP to cs.arizona.edu.  cd /icon/packages/unix
or /icon/packages/vms and get the READ.ME file there for further
information.

Executable binaries and related files are available for the following
UNIX platforms via FTP:

	Convex				NeXT
	DECstation (MIPS risc)		Sequent Symmetry
	HP 9000/700			Sun 3
	HP 9000/800			Sun 4 (Sparc)
	Iris 4D

cd /icon/binaries/unix and get the READ.ME there for further information.

The complete UNIX and VMS systems also are available on magnetic media
with printed documentation.  Shipping is included to addresses in the United
States, Canada, and Mexico.  The charge for shipping to other countries is
shown in brackets.

	UNIX	tape		  $30 [$10]
	UNIX	cartridge	  $45 [$10]
	UNIX	1.44MB diskettes  $25  [$5]

	VMS	tape		  $32 [$11]

Tapes are 1/2", 9-track, 1600 bpi.  Cartridges are written in QIC-24
format.

Payment to The University of Arizona may be made by check in U.S. dollars
drawn on a bank with a branch in the United States.  MasterCard and Visa
also are acceptable.

Direct questions to icon-project@cs.arizona.edu (not icon-group).
    
   Ralph E. Griswold			ralph@cs.arizona.edu
   Department of Computer Science 	 uunet!arizona!ralph
   The University of Arizona		602-621-6609 (voice)
   Tucson, AZ 85721			602-621-9618   (fax)

Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: comp.lang.rexx
Date:         Wed, 19 Aug 1992 17:30:03 PDT
From:         Dave Gomberg <GOMBERG@UCSFVM.BITNET>
Subject:      Re: Capturing System Command Output (was: SH Backquote)
              19 Aug 1992 23:16:49 LCL from <anders@LISE11.LISE.UNIT.NO>

OK, how about:

CAPTURE  --  a builtin function

CAPTURE returns a system defined value after executing a system command.

Usage:   X = CAPTURE('system_command'[,[address][,'stemname.']])

Effect:  system_command is executed as a system command, that is, as if
it had appeared by itself as an instruction, and were not a REXX instruction.
Any "returned value" defined by the operating system is returned as the
result of the function.  This may be a character string or a number or
nothing, depending on the operating system.   If the operating system
dictates returning nothing, the null string is returned.

Address is optional, if specified the result is the same as if the
line:  ADDRESS address system_command
had been encountered.

The lines of output which are the response of the command when issued by
the user (that which would go into a file if the operating system allowed
redirection of all user-device output in a single stream) are placed into
stemname.1, stemname.2, and so on, with stemname.0 being set to the number
of lines generated.  The stemname. is optional, if omitted, the lines are
placed FIFO in the most accessible part of the stack.  That is, the next
PULL will get the first line of output from the command, and so on for as
many lines as there are units change in the value of the QUEUED bif.

That cuts it to a single bif, with sensible name and syntax (although I
could live with the name SYSTEM or HOST too, if needed).  Do you like it?
From: marques@vax.oxford.ac.uk
Newsgroups: comp.lang.rexx
Subject: Re: SH backquote functionality in REXX?
Date: 13 Aug 92 16:50:34 GMT
Organization: Oxford University Library Automation Team

In article <41280@ogicse.ogi.edu>, jbthiel@ogicse.ogi.edu (John B. Thiel) writes:
> 
> What, if any, is a Rexx equivalent to the backquote mechanism as used
> in SH, whereby `process` is replaced by the stdio output of the
> process?
> 
> eg.
> now=`date`
> 
> -- 
> CSNET	jbthiel@cse.ogi.edu
> UUCP    ...{sun,tektronix,verdix}!ogicse!jbthiel

In a word, no.  Both OS/2 and VM REXX have ways of putting the output of 
commands into stem variables but these methods are implementation specific.
-- 
Jose Marques, Systems Programmer
 %INCLUDE STDDIS; /* Standard Disclaimer */
Newsgroups: comp.lang.rexx
From: glaser@guug.de (Edwin Glaser)
Subject: PC-REXX ISPF Panels
Summary: How to convert MVS-REXX ISPF Panels to Personal REXX 3.0
Keywords: PC REXX ISPF
Organization: Technical University of Munich, Germany
Date: Wed, 19 Aug 1992 06:58:23 GMT

Hello,

we are about to convert MVS-REXX programs to PC-REXX programms.
(COWLISHAN, Personal REXX 3.0). Since all MVS-REXX programs
include ISPF commands and panels, we have the question how
is it possible, without too much effort, to convert to PC-REXX 
windows.

Is it possible that a routine already exists whitch automatically
scans in ISFP Panels and creates window or even a ISPF packet
for PC ?

Thanks in advance.
--
    Edwin Glaser (glaser@guug.de) INA Waelzlager Herzogenaurach
Newsgroups: comp.lang.rexx
From: TICS28@waccvm.corp.mot.com (Alan Long)
Subject: REXX on a Macintosh
Organization: Motorola
Date: 19 Aug 1992 08:45:43 MST

     I'd like to try REXX on a Macintosh SE or Classic II.  I guess this
could be done with SoftPC and PC REXX.  Has anyone tried this or got any
comments?  Who supplies PC REXX? Or is there a Mac PC?

Alan Long,      Motorola, East Kilbride, Scotland
Newsgroups: comp.lang.rexx
From: jpr@sun4.lri.fr (Jean-Pierre Riviere)
Newsgroups: comp.lang.rexx,comp.os.os2.misc
Subject: Re: Stem vars as arguments?
Date: 13 Aug 92 09:14:49 GMT
Organization: Laboratoire de Recherche en Informatique


In article <ednstras.713591629@kraken>, ednstras@kraken.itc.gu.edu.au
(Michael Strasser) writes:
|> I am writing a complicated REXX program under OS/2 2.0.  I would like
|> to be
|> able to use a stem variable as an argument to an internal procedure,
|> but my
|> attempts have failed so far.

I too have encountered similar problems of which I wanted to post today...

|> Here is a simple example:
|> 
|> /* Init the stem var. */
|> Opts.Label = 'Select an option A-C, X'
|> Opts.0 = 4 /* No. options */
|> Opts.1 = 'A'
|> Opts.2 = 'B'
|> Opts.3 = 'C'
|> Opts.4 = 'X'
|> 
|> Choice = GetChoice(Opts)
|> 
|> /* ... */
|> 
|> GetChoice: PROCEDURE
|> ARG Stem  /* Stem var with options */
|> 
|> SAY Stem.Label
|> PULL Resp
|> FOR i = 1 TO Stem.0 DO
|> 	IF Resp = Stem.i THEN
|> 		LEAVE
|> END /* i */
|> 
|> IF i = Stem.0 + 1 THEN /* Default is Stem.1 */
|> 	RETURN Stem.1
|> 
|> RETURN Stem.i
|> 
|> /* End of example */
|> 
|> This doesn't work.  Nor does GetChoice(Opts.) or GetChoice('Opts') or
|> GetChoice('Opts.').  
|> 
|> Is there any way to do what I want?

Yes:
GetChoice: PROCEDURE EXPOSE Opts.0 Opts.1 Opts.2 Opts.3 Opts.4

This is the only way I found with my own script.
But for me this is not a practicable solution because I have
such things as guy.name.mail.sent.2
So I have to have NO procedure at all which could deal with my stem variables.
Of courses this is dangerous with the name of loop variables and is a very
good way to introduce bugs.

It would be nice if rexx allows that the components of a stem variable declared
as EXPOSEd.

So how would it best to deal with the construction of "objects" ?
For instance, guy is the class name of the object, and name is a variable
that I use to identify the guy in guy.name Knowing thew guy I can then
allow him a password for instance : guy.name.passwd
But If I have to declare guy.name.passwd and not change name nor passwd
in any procedure I will soon come to BIG PUZZLES too!

Anothe problem is that I have difficulty with avoidind painful select loop
with construct like :
/* assgin name of functions to stem var */
choice.quit = myQUIT
choice.read = myREAD
choice.write = myWRITE
say "choice ?"
parse pull this
call choice.this /* doesn't work - I tried variations but to no avail
(value, interpret) */

This is really a big trouble to me.

How would you then deal with that, you experimented rexx users ?

I too would greatly appreciate any help.

Jean-Pierre Riviere
LRI - Univ. Orsay
jpr@lri.lri.fr
-- 
  Jean-Pierre RIVIERE        |     ///
  LRI - Universite Paris Sud | \\\///
  e-mail : jpr@lri.lri.fr    |  \///
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: comp.lang.rexx
Date:         Fri, 14 Aug 1992 14:42:26 EDT
From:         "Lynne J. Worsfold" <LWORSFOL@PSUHMC.BITNET>
Subject:      Re: Stem vars as arguments?
              13 Aug 1992 16:48:23 GMT from <chappy@DUTS.CCC.AMDAHL.COM>

On Thu, 13 Aug 1992 16:48:23 GMT Chappy Cole said:
.
.
>
>/* Top level exec which calls another to set the stem 'Opts.' */
>'EXEC STEMFILL OPTS.' /* Pass stem name as argument */
>do i = 1 to Opts.0
>  say 'Opts.'i '=' Opts.i
>end i
>exit
>
>/* STEMFILL EXEC - Assigns hardcoded values to the passed stem in the calling
>exec */
>parse upper arg Stem .
>Mystem.0 = 4
>Mystem.1 = 'A'
>Mystem.2 = 'B'
>Mystem.3 = 'Z'
>Mystem.4 = 'Y'
>'PIPE stem Mystem.' ,   /* Put 'Mystem.' values into pipeline */
>  '| stem' Stem '1'     /* Put stream values into callers 'stem' */
>exit rc
>
>That is one way to solve your problem on VM/CMS with PIPELINES.  However, it
.
.
I am using CMS 8 with VM/ESA and I've tried this example and it works
just swell!!!!  I probably confused you because of how I phrased my
question - I apologize because I haven't mastered the Rexx lingo yet.
.
.
>Chappy

  I want to thank everyone on this list for their help and their examples.
I have not yet finished going through all the responses that I have rec'd
but, so far this example is the closest to what I want to do and the
easiest for me to understand at this point.

Just as a reminder, my original question was:
How can I declare (apparently an inappropriate word) values for stem
variables external to the main Rexx program in CMS?  I wanted to keep the
main Rexx program generic and keep the values for the stem variables
in another file - this will make changes to the values of the stem variables
easier.  The "big picture" goal for this main Rexx program is to
read in data from an electronic form which a faculty member has filled-
out and then add/update an SQL database with the information.
My progress to that goal is slow, but steady.  I'm sure you'll
be hearing from me again.
Thanks again for everyone's help!  I'm impressed with the amount of
Rexx & Pipes I have learned this week!!!!!

-----------------------------------------------------------------------
Lynne J. Worsfold                      Pennsylvania State University
Project Leader/Information Systems     Milton S. Hershey Medical Center
Internet: lworsfol@psuhmc.hmc.psu.edu  140 Sipe Ave
Voice:    (717) 531-6278               Hershey, PA  17033
-----------------------------------------------------------------------
Newsgroups: comp.lang.rexx
From: Jerry Campbell
Subject: Re: SH Backquote
Organization: Amoco
Date: Fri, 14 Aug 1992 19:04:47 GMT

In article 34260@cbmvax.commodore.com, chrisg@cbmvax.commodore.com (Chris Green) writes:
>In article <REXXLIST%92081316342058@UGA.CC.UGA.EDU> GOMBERG@UCSFVM.BITNET (Dave Gomberg) writes:
>>There is also the issue of system commands, as opposed to BIFs.
>>
>>For these, use the RXQUEUE function if you are an OS/2 user:
>>
>>   'DATE | RXQUEUE' ; PULL X
>>
>>if date generates only a single line.  Patrick was kind enough to
>>point this out for us.  Meanwhile, Patrick, is there also a RXSTEM
>>and if so, can you reproduce the help file for us please?   Many
>>thanks.   Dave
>
>
>	Similarly, in AREXX you do
>
>	'date | execio fifo' ; pull x
>-- 
>*-------------------------------------------*---------------------------*
>|Chris Green - Graphics Software Engineer   - chrisg@commodore.COM      f
>|                  Commodore-Amiga          - uunet!cbmvax!chrisg       n
>|My opinions are my own, and do not         - icantforgettheimpression  o
>|necessarily represent those of my employer.- youmadeyouleftaholeinthe  r
>|"A screaming comes across the sky..."      - backofmyhead              d
>*-------------------------------------------*---------------------------*

That piping operator you're using is a feature of an alternative shell, 
not the one packaged with AmigaDos, right?  The most useful implementation
I've ever used on CMS, Amiga, or Unix Rexx is probably Uni-Rexx's which goes
like:

      rc = Popen('unix cmd string')
      do while queued(); pull stuff; end

CMS has (or will have for me, we are stuck on VM/XA 2.1) PIPES and I understand
there's a real nice feature that will take the output (STDOUT) of a command
and place it directly in a compound (stem) variable for you.  Personally,  I
definitely prefer a thingy that takes that approach.  Something like:

      Call GrabOut 'cmdstring','stem_name.'

Seems like this approach would help abstract the problem of retrieving cmd
output.  Right now, everybody's using a different scheme each of which is
dependant on specific features of the shell/platform that you're on.  Sure,
somebody has got to those things into account, but I'd rather it be the
language implementor and not me, the programmer.         
  

Jerry Campbell
--------------------------------------------------------------------------
"When in doubt, write it in REXX, you can always port it later"
--------------------------------------------------------------------------

Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
X-Delivery-Notice:  SMTP MAIL FROM does not correspond to sender.
Newsgroups: comp.lang.rexx
Date:         Thu, 13 Aug 1992 12:34:21 DST
From:         VALOREV@DKIBMVM1.VNET.IBM.COM
Subject:      Expose of Variables
Comments: To: rexxlist@ucf1vm.cc.ucf.edu

One mentioned, that maybe under VM/ESA you could use a variable to expose
a list of variables.

To be more precise, this is a feature introduced in REXX Language Level 4.00
which also is adapted in the SAA CPI Procedures Language Level 2.

I don't know whether VM/ESA supports this level, but OS/2 ver. 1.3 as well as
2.0 supports this. In addition the CMS REXX Compiler also supports this.

It functions like this:

/**/
a=1
b=2
c=3
d=4
vars='a b'
call speak_out
exit

speak_out:
procedure expose (vars) d
say a b c d
return

screen output: 1 2 C 4

So as you see, the parentheses do the magic of exposing the content of that
variable, as well as the variable it self.

With Kind Regards
Victor Valore
Internet: valorev at dkibmvm1.vnet.ibm.com
Bitnet: valorev at vnet
Newsgroups: comp.lang.rexx
From: cse_stu@memstvx1.memst.edu
Newsgroups: comp.lang.rexx
Subject: AREXX talks to the serial port
Summary: How to interface arexx to serial comm.
Date: 19 Aug 92 09:41:11 GMT
Article-I.D.: memstvx1.1992Aug19.154111.3074
Distribution: world
Organization: Memphis State University

I'm tring to read some ASCI coming in on the serial port at 1200 baud. How do I
do it?
Newsgroups: comp.lang.rexx
From: ets@wrkgrp.COM (Edward T Spire)
Subject: Re: Capturing System Command Output (was: SH Backquote)
Organization: The Workstation Group
Date: Thu, 20 Aug 92 14:23:14 GMT

RZOTTO@DKNKURZ1.BITNET (Otto Stolz) writes:
: On Wed, 19 Aug 92 13:54:45 GMT Jean-Pierre Riviere said:
: > Well, I am not a specialist but whatthe hell is the "RESULT" var done
: > for ?
: 
: According to TRL (Section 14), and other sources, RESULT will always
: hold the result of the REXX function finished most recently. Example:
:      say time()
: and
:      call time
:      say result
: are semantically equivalent.  (Though my test run resulted in a dis-
: crepancy in the least significant figures :-)
: 
: According to the same authoritative sources, the only variable affected
: by a command to an external environment, is RC. It will hold the return
: code of the command executed most recently.
: 
: In all operating systems I know of (admittedly not including Amiga), the
: return code is a different concept from the standard output of a command.
: Hence the current thread on how to grab the standard output *in addition
: to the rc*.
: 
: > Would not be the better way be
: > "ls -l ~"
: > dir = result
: 
: Definitely not, as this would invalidate many existing REXX programs,
: viz. programs that depend on the RESULT variable not being affected by
: a command to an external environment.
: 
: > (This is the only available way to do it with arexx btw)
: 
: Hardly believable! If indeed so, Arexx would be grossly non-standard.
: Please test your example, and report again.
: 
: > It's common rexx anf follows Cowlishaw's rules. (as far as I under-
: > stood it...)
: 
: Definitely not (cf. supra). You'd better read Cowlishaw again!

AREXX does contain some features that do not conform to Cowlishaw's
rules.  In some cases this is somewhat understandable, such as the
issue we're discussing here, where Cowlishaw gave no guidance, and each
implementer was forced to roll his own.  In other areas (such as I/O)
Bill Hawes simply did something he thought was better than what
Cowlishaw had suggested.  He may have been "right" about that, but it
is causing some problems in the ANSI REXX efforts.

========================================================================

Ed Spire                           email: ets@wrkgrp.com      (on uunet)
The Workstation Group              voice: 800-228-0255
6300 River Road, Suite 700            or  708-696-4800
Rosemont, Illinois  60018            fax: 708-696-2277
Newsgroups: comp.lang.rexx
From: ets@wrkgrp.COM (Edward T Spire)
Subject: Re: Capturing System Command Output (was: SH Backquote)
Organization: The Workstation Group
Date: Fri, 21 Aug 92 15:28:14 GMT

flass@136.161.128.3 (Peter Flass) writes:
: >   The committee is leaning towards providing yet another special variable
: >   to indicate the completion status of the command to the external
: >   environment in a standard manner.  ...
: >   ...                Hence the committee is leaning towards adding the
: >   special variable "rs", which would be assigned the value -1, 0, or 1
: >   upon the completion of an external command, meaning failure, normal,
: >   or error status.
: 
: This is a tall order -- A REXX implementation would have to know the
: significance of _all possible_ return codes from _all possible_
: environments.  Since environments are being multiplied constantly
: it might be less confusing not to try.

REXX can only ADDRESS commands to environments that have either had
specific REXX support added to them (i.e., an application such as XEDIT)
or that have a fairly sophisticated interface routine (such as is
normally used to address commands to the underlying OS.)  In either case
it is the responsibility of the "callee" (i.e. the application or the
interface routine) to indicate command completion status.  For an
application that is going to support a REXX addressible environment this
is usually not a problem.  It can be a problem for some operating
systems:  In Unix, we can report only success or not, we cannot easily
differentiate between error and failure.

========================================================================

Ed Spire                           email: ets@wrkgrp.com      (on uunet)
The Workstation Group              voice: 800-228-0255
6300 River Road, Suite 700            or  708-696-4800
Rosemont, Illinois  60018            fax: 708-696-2277
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU