Date:         Fri, 14 Nov 1997 16:08:27 GMT
Reply-To:     REXX Programming discussion list <REXXLIST@UGA.CC.UGA.EDU>
Sender:       REXX Programming discussion list <REXXLIST@UGA.CC.UGA.EDU>
From:         pforhan@MILLCOMM.COM
Organization: IBM Rochester
Subject:      Re: Why REXX is not my favorite scripting language (was Re:
              regular expression matching)

In <346B918A.4709@mail.state.wi.us>, Doug Quale <qualed@mail.state.wi.us>
writes:
>pforhan@millcomm.com wrote:
>> What a strange view.  I have never seen anything done in a shell script
>> that could not have been done with REXX.  It seems perfect for scripting
>> and text processing (for example, CGI).  In my experience, it is roughly
>> equivalent to Perl in abilities.  Granted, this was a couple years ago...
>...
>Simple facilities avaible in Unix shells not in REXX
>  file tests (exists, readable, writable, executable, zero length,
>directory, etc.)
>  background processes
>  I/O redirection
>  piping
 
One of the things that impressed me early on about REXX was the way
it interacts with the operating system, as you mention below.  Much
of the functionality you mention above can be accomplished via OS
calls.  I know I have used piping, redirection, and background stuff
in REXX.
 
>Since perl has all shell facilities plus many, many more, "roughly"
>equivalent to Perl is true only if one takes a very rough view of
>roughly.
 
There sometimes is merit in integrating such features in the langauge.
I do not know Perl well enough to say, in this case.  For REXX, I guess
I am glad it does not act as an OS because of its nature and use as
a support language for applications.
 
I should note here that it would be entirely possible for someone to
make a wrapper for REXX that provides services as you name here, and
below.  (Honest question: Does Perl offer this form of integration?)
 
>It is true that PARSE is a central point of REXX. Regular expressions
>are a central point of Perl and awk. RE's are more powerful than PARSE,
>hence Perl and awk are more powerful than REXX.  If I weren't familiar
>with RE's I would probably think PARSE is wonderful, but by comparison
>to RE's, PARSE just doesn't carry the freight.
 
I would dare say that REs and PARSE are almost different applications.
Maybe PARSE could be called "the working man's RE."  In a way.  But
their purposes are somewhat different.  PARSE does more in the way
of, well, parsing; splitting something up based on characteristics
and positioning and what-not.  REs are more for finding things.
 
There is no question that REs are powerful.  But they cannot do what
PARSE does, without extensions.  To my knowledge, there is no such
syntax as "^%1.*%2$" (where %1, %2 are variables to be loaded...)
in any RE, is there?  Come to think of it, I doubt you can do that
query exactly in REXX, either.  Here, my lack of knowledge of both
REXX and Perl show through... so forgive me if I am really wrong.
 
>The STREAM instruction is not so terrible in itself, although it is a
>very late addition to REXX.  IBM still does not support STREAM in their
>REXX offering on MVS, their flagship operating system.  Because of this,
>it is impossible to use STREAM in a portable way.  Since MVS is the
>primary platform I use REXX on, I can't use STREAM at all.
>Unfortunately BREXX extensions don't help me here. I need better
>facilities in the standard language (and libraries).
 
BREXX source is available; you wouldn't happen to have a C compiler
for that, would you?
 
>When I say the REXX I/O model is bizarre, I am referring specifically to
>data queue.  That is a truly peculiar notion.  Among other things, it is
>only useful in a single process environment, a la CMS.
 
Are you refering to the stack?  Where you pull stuff off, but once it
runs out, is goes interactive?  Yeah, I thought that a little odd
when I started.  In fact, more odd was the way that OS (MUSIC/SP)
supported file I/O: read in a specified number of lines, drop them
into the stack.  Flipped me out for a little while.  =)  Ah, but I was
young then.
 
>The REXX statement continuation syntax is the best statement
>continuation syntax IBM has ever designed, but since all IBM's language
>design work seems oriented to entry on punched cards that's saying less
>than nothing.  Real languages allow
 
As was mentioned elsewhere in this thread already, syntax is syntax.
I don't particularily like C syntax, but it does no good complaining about
it...
 
FWIW, looking back, I see that MS BASIC syntax was a nightmare.  I would
have hated writing that parser.  Some commands took (x,y), some took x,y,
some took (x,y)-(x1,y1),z etc.  All bound to one line, as I recall, too...
 
>Personally I find other aspects of the syntax of REXX a bit annoying,
>particularly conditionals.  I don't like the special cases involving the
>semicolon
>
>IF x < 0; THEN x = (-x)**0.5; ELSE x = x**0.5;  /* OK */
>IF x < 0 THEN x = (-x)**0.5; ELSE x = x**0.5;   /* also OK */
>IF x < 0 THEN x = (-x)**0.5 ELSE x = x**0.5;    /* syntax error */
>IF x > 0 THEN NOP; ELSE x = x*x;   /* OK */
>IF x > 0 THEN ; ELSE x = x**x;     /* syntax error */
 
Well, my first recommmendation is to not to do this, at all.
Always split up if/then/else statments.
 
>There are more of these surprises, and the surprises are often more
>surprising when the conditional is written on several lines instead of
>just 1.  The design of the REXX IF instruction also allows only a single
>expression in the THEN and ELSE clauses, requiring frequent use of
>DO...END blocks in conditionals. (This mistake is also in Pascal, but
 
Well, many languages are like this, including C and C++.  I prefer Ada,
which, IIRC, always forces the use of an END IF.  Modula-2 is like this
also, no?
 
>REXX scripts accept only a single argument. That means that every REXX
>script must parse its own arguments, rather than letting the calling
>environment handle argument parsing. (This is a design flaw that was
 
Not that it is hard, using parse and friends.  Far easier than C, IMHO.
 
>repeated in PCDOS/MSDOS.)  I frown at the "GREAT RUNES" IBM mainframe
>mentality of uppercase translation by ARG and PULL not to mention
 
As I am sure you know, you can use parse arg and parse pull to
eliminate this problem.
 
>default values for undefined variables. I don't like the interface to
>external environments.  Although sending unrecognized expressions to the
>external environment may have seemed like a great idea for a scripting
>language, I find it confusing and error prone.  It also necessitates the
>odd CALL instruction.  Therefore
 
My suggestion would be to use one or the other consistently.  If you like
communication with the OS, though, use the x=oscmd() form.
 
>REXX does not provide a good means of communication with commands
>submitted to external environments.  Although it is suggested to use the
>data queue for this purpose, the data queue itself is a strange idea
>that limits you to a single process environment. Unix backticks are
>infinitely superior in this regard.
 
Why not just seperate the commands into seperate steps, as I am sure
unix shells do, anyway?
 
/* contrived example below: */
x=ls("s*illy")
y=cat(x)
/* someone correct my syntax here, it's been a while...*/
 
>not a part of standard REXX, since it is an abomination.)  REXX has no
>facilities for formatted I/O (akin to printf).  This is extraordinarily
>abnoxious.  The REXX SAY command is almost useless -- it can only write
>complete lines (no way to supress the newline!)
 
While suppressing the newline is convenient, often you can just wait
until you have a line of data... or just write to a temporary variable.
 
Believe me, REXX is not the end-all and be-all of programming languages,
or even scripting languages, I am sure.  But it is easy to use,
powerful, and well-suited to rapid development.
 
Pat.