REXX and (NOT versus!) Perl
Scott Ophof
out how y'all think about the issues.
-----------------------------------------------
A bit dated, I know. Still.. :-)
Request:
If in the following anyone can discover a negative comment re Perl
or REXX, please post it on comp.lang.rexx or REXXLIST. I'm not a
regular reader of comp.lang.perl...
On 28 Feb 93 01:26:42 GMT Larry Wall said "Re: scope of labels":
>Sorry, you pushed one of my hotter hot buttons.
Dunno who did that, and what. Not really relevant anyway. :-)
What I want to do is clear up what seems to be a misconception Larry
had back then, and one that more people might have. I'm curious as
to your opinion of REXX after your presentation with Mike Cowlishaw
at the REXX Sympos; sadly enough I wasn't able to be there. :-(
As I see REXX, its purpose is to be a very-simple-to-understand-
and-use language for the average user on effectively any opsys.
This means it must be easy to READ, which implies the absence of
intricate or complicated constructions. It also means that use of
non-alphanumeric characters and highly abbreviated commands is not
advisable. The closer the language can be to what you are reading
now, the better REXX would achieve its goal.
Like Perl, REXX is based on string operations. There the similarity
ends, and each language goes its own way. From the very little of
Perl that I've seen, I get the impression that Perl users (like many
Unix users) prefer a syntax that is "short & sweet", ie. "say what
you have to say and no more". REXX users seem to prefer verbosity
and a minimal chance of surprises due to overlooking a 1-char typo.
Yes, verbosity increases the chance of typos, I fully agree.
In general I feel that Perl users may have a more mathematical bent.
People who may not have higher aspirations than string operations
of the simple kind may well find REXX sufficient. So not only is
the entry level of REXX lower, but also *different*. I also would
not in the least be surprised if Perl users can make strings jump
through hoops that REXX users wouldn't/couldn't even dream of.
BUT!!
>If you want to see some interesting arbitrary restrictions, go read the
>Rexx book. Like, a conditional expression MUST return 0 or 1.
Huh? The result of a conditional is either TRUE, or it's FALSE.
And when they have been given the values of 1 resp. 0, then what
else can they be? Yes, I know there are languages where one of
the two has a definite value, and the other can be anything else.
My question here is what is "arbitrary" here.
>Hex and binary strings can have embedded whitespace, but ONLY in
>certain locations.
With READABILITY being of prime importance, this restriction makes
quite a bit of sense, I'd say. So rather than arbitrary, it seems
to me based on a very valid premise.
>It's an error to use something as a number that doesn't
>look ENTIRELY like a number.
Again, it makes for easier READABILITY, and UNDERSTANDABILITY when
something goes wrong. Remember that it's very likely that the user
is NOT necessarily very interested in higher mathematics.
In fact, I wish "numbers" in REXX were defined as only the decimal-
based ones. As it is, so are binary and hexadecimal. :-(
>And, of course, there's no GOTO...
(grin) Sorry, gotta "disillusion" you here. There is no command
named GOTO, but one can abuse the SIGNAL instruction as such.
The amusing thing is that one can to some extent tell the background
of REXX users by the way they use SIGNAL; is it to set an error-trap
on or off, or is it used to jump to some (arbitrarily named) label?
>Certainly, I've put some restrictions into Perl, but they tend to be
>of a more basic sort.
>You can't have a subroutine with multiple entry points.
>You can't use a variable for a label.
Multiple entry-points and using a variable when jumping to a label
allow REXX users to do thing they otherwise couldn't do. To be able
to allow those things to be done when only single entry-points and
no variable labels are allowed would mean making REXX less READABLE,
and thus less easily UNDERSTANDABLE.
>You can't write a dangling "then" statement.
I'd like to see an example of what you mean. Something like?:
If ... then ...
instead of?:
If ... then ... else ...
REXX can be learned and used by a John Doe type user (like me!)
without referring to a manual for more than 5-10 minutes.
Perl is a language I won't be able to comprehend enough to write
even a 3-liner like:
/* Display a two-word greeting */
Say 'Hello world!'
Exit
Heck, I even have trouble understanding that things like shell-
variables exist and have to be careful with the "$" character.
But this is a failing on *my* part, not of Perl.
>These are meaningful restrictions that
>tend to increase the functionality or efficiency of other parts of
>the language. However, I am never happier than when someone tries
>something in Perl that they don't expect to work, and it does anyway.
Very understandable. I get the same feeling when I manage to do
something in REXX that I thought I couldn't. The level may be
different, but that isn't the point. It's being able to do things
one thought impossible.
Y'know what I'd like to see? A language as easily READABLE as REXX
and as easily UNDERSTANDABLE *FOR* *JOHN* *DOE*, with the power of a
language like Perl or C, etc. Can y'all see that a syntax like C,
Perl, regexps, and such just would NOT be suitable for that purpose?
Regards, and thanks for listening.
$$\
Jack F. Hamilton
>I posted this to the comp.lang.perl, but would also like to find
>out how y'all think about the issues.
>In general I feel that Perl users may have a more mathematical bent.
>People who may not have higher aspirations than string operations
>of the simple kind may well find REXX sufficient.
String operations are often more difficult than math operations, simply
because many languages don't have many built-ins dealing with strings.
Since I hardly ever do anything that goes beyond arithmetic, but do a lot
of string manipulation, both REXX and Perl are godsends to me.
I don't think that my aspirations are lower because I'm not doing math.
>I also would
>not in the least be surprised if Perl users can make strings jump
>through hoops that REXX users wouldn't/couldn't even dream of.
I'd be surprised. Some REXX users have big dreams, as shown by the recent
regexp-in-REXX discussion.
>>If you want to see some interesting arbitrary restrictions, go read the
>>Rexx book. Like, a conditional expression MUST return 0 or 1.
>
>Huh? The result of a conditional is either TRUE, or it's FALSE.
>And when they have been given the values of 1 resp. 0, then what
>else can they be? Yes, I know there are languages where one of
>the two has a definite value, and the other can be anything else.
>My question here is what is "arbitrary" here.
I definitely agree that that's an arbitrary restriction.
>Again, it makes for easier READABILITY, and UNDERSTANDABILITY when
>something goes wrong. Remember that it's very likely that the user
>is NOT necessarily very interested in higher mathematics.
>In fact, I wish "numbers" in REXX were defined as only the decimal-
>based ones.
What would be the advantage of that?
>REXX can be learned and used by a John Doe type user (like me!)
>without referring to a manual for more than 5-10 minutes.
>Perl is a language I won't be able to comprehend enough to write
>even a 3-liner like:
> /* Display a two-word greeting */
> Say 'Hello world!'
> Exit
That's really a 1-liner, since (in many cases) the opening comment isn't
necessary, nor is the Exit statement. I admit, it's not as obvious in
Perl, but the manual's pretty good for that kind of thing.
print "Hello world!\n";
>Heck, I even have trouble understanding that things like shell-
>variables exist and have to be careful with the "$" character.
>But this is a failing on *my* part, not of Perl.
That is a problem, remembering the difference between $\and $| and $/ and
so forth, especially if you're not a shell or C programmer.
>Y'know what I'd like to see? A language as easily READABLE as REXX
>and as easily UNDERSTANDABLE *FOR* *JOHN* *DOE*, with the power of a
>language like Perl or C, etc. Can y'all see that a syntax like C,
>Perl, regexps, and such just would NOT be suitable for that purpose?
REXX does have most of the power of Perl, if you leave out regular
expressions and forks/processes/pipes (which are operating system
dependent). REXX and Perl are just different. Neither one is better than
the other (although I'd be willing to say that either is better than COBOL,
which is more difficult to read and write).
--
------------------------------------------------------------------------
Jack Hamilton j...@netcom.com kd6ttl@n0ary.#nocal.ca.us.na (AMPR)
Post Office Box Box 281107 San Francisco, California 94128 USA
Stephen E. Bacher
Larry>Rexx book. Like, a conditional expression MUST return 0 or 1.
Scott>Huh? The result of a conditional is either TRUE, or it's FALSE.
Scott>And when they have been given the values of 1 resp. 0, then what
Scott>else can they be? ...
[philosophical question about the meaning of "arbitrary" deleted as a red herrin
g]
Larry>Hex and binary strings can have embedded whitespace, but ONLY in
Larry>certain locations.
Scott>With READABILITY being of prime importance, this restriction makes
Scott>quite a bit of sense, I'd say. So rather than arbitrary, it seems
Scott>to me based on a very valid premise.
Larry>It's an error to use something as a number that doesn't
Larry>look ENTIRELY like a number.
Scott>Again, it makes for easier READABILITY, and UNDERSTANDABILITY when
Scott>something goes wrong. ...
[comment about innumerate users deleted as another red herring]
I'll add my voice to the defenders of REXX. All of these decisions were
designed to protect the programmer from incurring incorrect results due
to an execution foulup. If a conditional expression generates something
other than 0 or 1, the problem is nipped in the bud before it can send
the missile shooting off in the wrong direction. Same applies to a
binary or hex constant string specified with the wrong character grouping.
(This was brought up at the REXX symposium.) Suppose a programmer writes
a hex constant and leaves out a character. The only way the interpreter
has a chance of catching the error is to say "Hey, you only had 3 hex digits
in that group instead of 4. Are you sure that's what you meant?"
And it has nothing to do with higher mathematics. I didn't see any reference
to Perl being better than Rexx because it had a complex/trig function library...
?
Larry>And, of course, there's no GOTO...
Scott>(grin) Sorry, gotta "disillusion" you here. There is no command
Scott>named GOTO, but one can abuse the SIGNAL instruction as such.
"Abuse" is right. Few things are more annoying in a REXX script than the
uncalled-for use of SIGNAL as a GOTO.
- seb
Larry Wall
: REXX does have most of the power of Perl, if you leave out regular
: expressions and forks/processes/pipes (which are operating system
: dependent).
Hmm, I suspect you'd have to leave out the list processing too. REXX doesn't
really support true lists, though it has several ways of emulating them.
And I'm sure various people would complain if I chopped out the file
test operators, or the directory operations, or the report formats, or
the built-in sort, or the ability to mung binary data directly, or the
ability to store associative arrays (stem variables) in files. Of
course, much of this can be supplied by external routines. But then,
that's operating system dependent, to purloin a phrase.
: REXX and Perl are just different. Neither one is better than
: the other (although I'd be willing to say that either is better than COBOL,
: which is more difficult to read and write).
We'll just have to agree to agree on that one.
Larry Wall
lw...@netlabs.com
Alex Moffat x238
>...
>Hmm, I suspect you'd have to leave out the list processing too. REXX doesn't
>really support true lists, though it has several ways of emulating them.
The same function in REXX is generally done by using stem variables.
For example rc = foo(AVariable, "AStem") where conventionally AStem.0
will return the number of elements returned by foo and AStem.1 through
AStem.n contain the actual elements. BTW these could easily be of the
form AStem.a.b.c.d e.g Contact.2.Name.First etc. To process use
do i = 1 to AStem.0
do something to AStem.i
end
Or the data queue with the pull, push and queue instructions.
Horses for courses.
--
Alex Moffat al...@evtech.com Evolutionary Technologies Inc.
Stephen E. Bacher
>>>the two has a definite value, and the other can be anything else.
>>>My question here is what is "arbitrary" here.
>>I definitely agree that that's an arbitrary restriction.
>
>herring here). IMHO *both* are an arbitrary choice.
I had assumed that by "arbitrary" it was meant that the choice of
which values to represent truth and falsity was arbitrary. Lisp uses
the symbols T and NIL. Actually, Lisp uses NIL for false and "anything
that is not NIL" for true. Similarly, C uses zero (any flavo[u]r)
for false and anything that is not zero for true.
So, I considered that to be a red herring, because the issue was not
WHICH values you assign to TRUE and FALSE, but WHETHER you should choose
only a finite set of values and reject all others as "in error". I wished
to point out the advantage of using only certain values.
But now we are talking about an "arbitrary restriction" rather than
an "arbitrary choice". I do not think the restriction is arbitrary.
I think it has a very definite purpose. Restricting the contents of
a file name to 8 or fewer alphanumerics - now THAT is arbitrary.
>Wasn't the REXX compiler already available when that shuttle blew
>up some time ago? (grin)
Nope - that was 1986; SAA did't even exist yet, so there was no REXX
on MVS - I was stuck with TSO CLIST. Anyway, the Challenger
disaster was a hardware problem (faulty O-rings).
>Which leads me to another point. For *my* purposes the tracing
>facilities in REXX are simply superb. Verbose where *I* feel a need
>for it (in general). Verbose elsewhere also ...
Yes, verbose all right, but I usually don't want verbosity.
I usually want to say "let me set a breakpoint whenever I get to
this instruction and see what happens". REXX trace is too much of a
good thing. I need a real debugger, not interminable trace output
that cannot even be easily redirected to a file (I'm sure that
imc has already fixed this problem... :-)
- seb
P.S. Yes, it's safe to type a backslash in vi. In fact, it's one of
the safest characters you can type, because it is not defined as any
sort of vi command!
Larry Wall
That's what I said, it has several ways of emulating lists. (And you
left out word() and friends.) None of these emulations is entirely
satisfactory. Stem variables can't be shifted or spliced (at least not
efficiently). Data queues, er, that is, THE data queue, can't be
subscripted or printed ("said") directly. The word() et al functions
don't scale well, and presume that list elements will contain no spaces.
In Perl any given list variable can be assigned, subscripted, pushed,
popped, shifted, unshifted, sliced, spliced, packed, unpacked, split,
joined, printed, reversed, sorted by arbitrary criteria, searched for
subsets matching patterns, and passed to the operating system as a
command. All of these operations are portable, efficient, and built-in.
What's worse, these operations are *necessary*. When you don't have
them, you end up re-inventing them over and over, sometimes wrong.
Larry
Jin S Choi
> In Perl any given list variable can be assigned, subscripted, pushed,
> popped, shifted, unshifted, sliced, spliced, packed, unpacked, split,
> joined, printed, reversed, sorted by arbitrary criteria, searched for
> subsets matching patterns, and passed to the operating system as a
> command. All of these operations are portable, efficient, and built-in.
It's rather impressive, to hear them enumerated like that. Perhaps we
should rename it LISP, for LISt Processing....
--
Jin Choi
j...@athena.mit.edu
matthew green
: expressions and forks/processes/pipes (which are operating system
: dependent).
uh, perl wouldn't be anywhere near the god-like language it is with out
those above meantioned, brilliant features.. it becomes like C then..
hard to manipulate strings... ugh..
: REXX and Perl are just different. Neither one is better than
: the other (although I'd be willing to say that either is better than COBOL,
: which is more difficult to read and write).
i can't disagree with the second bit, but i don't enjoy REXX much more..
m..
Jack F. Hamilton
>In article <jfhC8E...@netcom.com> j...@netcom.com (Jack F. Hamilton) writes:
>: REXX does have most of the power of Perl, if you leave out regular
>: expressions and forks/processes/pipes (which are operating system
>: dependent).
>
>uh, perl wouldn't be anywhere near the god-like language it is with out
>those above meantioned, brilliant features.. it becomes like C then..
>hard to manipulate strings... ugh..
Regular expressions are brilliant, yes, and from what I've seen (not all
that much), Larry's implementation of them in Perl is among the best of all
implementations. However, for string manipulations that don't involve
regexps, I find REXX easier to use than Perl. It might just be because I
like a certain amount of verbosity.
Pipes are available in some versions of REXX, with CMS Pipelines (and MVS
Pipelines, which apparently exists but isn't talked about). I don't know
enough about the PC versions of REXX to say whether any of them support the
rudimentary pipes available in DOS.
Being like C is not necessarily a good thing. Remember, most gods are not
only powerful but also not subject to human understanding.
F. Scott Ophof
>In various articles, Scott said:
(OOPS!) (near-)duplicate postings?
>S> REXX users seem to prefer verbosity
>S>and a minimal chance of surprises due to overlooking a 1-char typo.
>S>Yes, verbosity increases the chance of typos, I fully agree.
>Possibly, but on the other hand the typos are much easier to spot.
Yes, and THAT is EXACTLY my point! Plus that (as I think I said) a
typo in a REXX keyword generally causes one of REXX's error messages
to automagically appear BEFORE fatal harm is done.
Verbosity *does* have its good sides, especially for types like me
who cannot stand to program without typo[e]s... ;-)
>Larry>You can't write a dangling "then" statement.
>S>I'd like to see an example of what you mean.
>I don't know why it's called "dangling", but I believe he means you can't
>write:
> if x=3 then say 'Hi!'
>rather you must write
> if x=3 then do; say 'Hi!'; end
>(Of course, the "do" and "end" are actually curly brackets). This seems
>like somewhat of an arbitrary restriction to me...
Oh. I though Larry might've meant:
If .. then ..
in other words, withOUT an ELSE part. Never thought of what you're
suggesting as possibility. (Re "arbritrary": (hehehe) )
>S> Now if there was a language with the mindset of REXX, but designed
>S> for math processing (ie. READABLE and UNDERSTANDABLE)...
>What's wrong with the math processing in Rexx?
Nuttin's wrong. It was meant exactly as stated, as a wishdream.
Remember that the strength of REXX lies in its string processing
capabilities and easy-to-understand mindset, when compared to other
lingos. Now take a language explicitely set-up to work with math,
and try to translate its syntax and mindset to that of REXX.
Anyway, *I* wouldn't miss the math stuff. The string processing is
what I'm after.
..[Arbitrariness: a conditional expression MUST return 0 or 1]..
>Further, it is sometimes useful to have the logical "and" and "or" return
>the value of one of their operands when appropriate. I just looked up perl,
>and it does this. C does not. REXX/imc does it a different way from perl:
> x & y = {x if y is true; 0 if y is false}
> x | y = {x if y is false; 1 if y is true}
>So you can say: a = (1 & x='A') + (5 & x='B') + (9 & x='C')
> or: b = (7 | y\='A') * (3 | y\='B') * (5 | y\='C')
>...
>(similarly for b and y). Some people will immediately leap up and say "Ugh,
>how horrid!" Perhaps they are right. I got the idea from Sinclair BASIC...
Doesn't seem strange to me that C cannot do this; C is very strict
with its datatypes, as two REXX implementors living in Greater
Europe have told me. (Coincidence that their last names both start
with a "C"? >:-) )
Anyway, I'm glad REXX allows this behaviour; it has made programming
easier and more fun for me over the years.
On Fri, 11 Jun 1993 16:30:37 -0400 Ander Christensen said:
>If you want a compact and "unreadable" way of doing this _within_ the
>definition of TRL, you can do it like:
> a = 1 * (x='A') + 5 * (x='B') + 9 * (x='C')
I must be going batty! This seems quite readable to me!
But I had another version which imho is even more REXXish, but it
doesn't use boolean logic:
a_pos = wordpos(a,'A B C')
x = word('0 1 5 9', a_pos + 1)
which imho becomes less readable when combined as follows:
x = word('0 1 5 9', wordpos(a,'A B C') + 1)
>S> Well, hexadecimal numbers are also valid "numbers" in REXX,
>'Scuse me? I must have missed something here.
I think I gave an example somewhere else. Anyway, try determining
to which datatypes the following belongs:
14E6
You should come up with at least Number and heXadecimal...
My point is that if you don't *know* which one it is, testing for
its datatype can produce inconclusive results (which is indeed a
valid reason for C's insistance on the datatype of an entity).
It's about 2.5 years ago that Otto Stolz and Horst Kiehl (among
others) mentioned something similarly obfuscating on REXXlist.
>S> So in "vi" I type "$", want to correct, hit "\" instead of BACKSPACE
...
>However, the backslash still remains, and it can be quite annoying.
>It still applies to the C-shell, so when I type a "\" by mistake [..]
Exactly. And exactly. :-(
>S> Confession: I abused SIGNAL in the beginning. My excuse was still
>S> being under the influence of Fortran and job-control lingos on other
>S> opsyses back then...
>I didn't. I learned to program with the REXX Primer, and if I remember
>correctly, the signal instruction comes with a warning, like "NB This is not
>meant to be used like a GOTO instruction" [...]
In itself still a pointer to those who are looking for a GOTO, or
*anything* they can use as such to JUST GET THE PROGRAM WORKING!!
(Ie. when they get frantic...) :-)
>Anyway, don't all texts say this? If not, then they should.
TRL-2 doesn't, at least not in the definition of SIGNAL.
Soon after I was "shown the light", my "boss" started grumbling,
getting unhappy with REXX. Couldn't understand what his problem was
till he showed me the program. My laughing fit didn't exactly make
him feel any better, till I managed to calm down and explain he was
in the same dilemma I'd just gone through. :-)
"SIGNAL" and "coffee!" seemed synonyms for the next week... (grin)
Regards.
$$\
F. Scott Ophof
>Hmm, I suspect you'd have to leave out the list processing too. REXX doesn't
>really support true lists, though it has several ways of emulating them.
List processing has been discussed a number of times here, and as I
said in a previous related thread, it would be a useful enhancement
from my point of view (I think).
>And I'm sure various people would complain if I chopped out the file
>test operators, or the directory operations, or the report formats,
> or the ability to mung binary data directly,
All indeed preferably external is my vote, except where internal is
necessary to establish permanence (when I do a chdir, then I want it
to remain so until *I* want it otherwise).
A built-in sort (or in an external function package (library)), also
capable of sorting stems with NON-numerical tails, would be nice.
The ability to store stems with tails of any kind should become a
part of the I/O model, I feel. And is currently missing.
Regards.
$$\
Dave Gomberg
list processing? It seems to me it has nearly the best support of any
language (with the possible exception of awk) because of its associative
memory. Dave
Dave Gomberg, role model for those who don't ask much in their fantasy lives.
GOMBERG@UCSFVM Internet node UCSFVM.UCSF.EDU fax-> (415)731-7797
Jack F. Hamilton
>>S> Now if there was a language with the mindset of REXX, but designed
>>S> for math processing (ie. READABLE and UNDERSTANDABLE)...
>>What's wrong with the math processing in Rexx?
>
>Nuttin's wrong. It was meant exactly as stated, as a wishdream.
>Remember that the strength of REXX lies in its string processing
>capabilities and easy-to-understand mindset, when compared to other
>lingos. Now take a language explicitely set-up to work with math,
>and try to translate its syntax and mindset to that of REXX.
One of REXX's strength's, in my opinion, is its arbitrary precision
arithmetic. That's not common among general-purpose languages. Want pi to
6000 decimal places? Easy enough. You just need lots of memory.
Anders Christensen
>> a = 1 * (x='A') + 5 * (x='B') + 9 * (x='C')
>
> [...] But I had another version which imho is even more REXXish, but it
> doesn't use boolean logic:
> a_pos = wordpos(a,'A B C')
> x = word('0 1 5 9', a_pos + 1)
No, it's not the same. Consider what happens when 'a' is a phrase,
e.g. the phrase 'B C' ....
Regards,
-anders
Anders Christensen
> Can someone please expand on the comment that REXX has poor support for
> list processing? It seems to me it has nearly the best support of any
> language (with the possible exception of awk) because of its associative
> memory. Dave
I can try ...
First, Rexx doesn't _really_ have lists, 'only' associative arrays.
I'm not sure what is the correct definition of a 'list', but it should
at least have the possibility of:
1) Store zero or more values, where each value can be any string.
2) Maintain a strict ordering of the elements, independent of the
_values_ of the elements (given any two elements in a list, one
will _always_ be 'in front of' the other), and allow the
programmer to retrieve all elements in that order. This separates
it from a set.
3) Allow the programmer to access any single value ('random
access'). This separates it from a queue or a stack.
Now, although Rexx has associative arrays instead of list, the power
of associative arrays is sufficient to _emulate_ lists. In effect,
that's what is done with EXECIO and other programs when they create an
associative array having tails '1', '2', '3', etc, and the number of
such tails is stored in the tail '0'.
It's easy to see that this particular use of associative arrays
satisfies points 1-3 above. However, there are several problems with
this method:
* It tend to be slow. After all, associative arrays is a rather
'expensive' datastructure, and when used as a list, you don't
exploit all the power (but the interpreter still has to do all the
bookkeeping) of associative arrays.
* It's sometimes a bit difficult to manipulate a list as a structure.
You have to pass the name of the stem, you can not pass a stem
collection. This is really a restriction in Rexx itself, and it
applies equally to variables and associative arrays. If the
suggested pass-by-address is introduced, it might help.
* There is no simple way to handle _sublists_. I.e., concatenating
two list, extracting parts of a list into an independant list, or
reversing the order of a list (except for coding it as loops).
* There is no "list" variables in Rexx, i.e. there is no way to
assign the stem collection "foo." to the stem collection "bar."
(except for coding it as a loop). In fact, there is _nothing_ in
Rexx that support this special usage of associative arrays, to the
user often ends up writing a lot of loops. It is just a common
programming idiom.
Using the stack, points 1 and 2, but _not_ 3 are satisfied, so the
stack is not a very good structure for holding a list. Often, one
needs operations like appending and retriving values from either end
of the list. For this, the stack suffice ... almost. The stack has the
ability to add a value to both ends, but can only retrieve a value
from the top (or is it the bottom :-)
For associative arrays used as lists, it is particularily time
consuming to add or delete an element in the front of the list, since
it requires all other elements to be physically moved. Given the fact
that the associative array is indexed by _strings_, and probably
maintained in a hash table, this is _not_ a trivial operation.
Efficient list operations requires a completely different internal
datastructure than does associative arrays.
So, Rexx _does_ have poor support for list processing. Whether or not
Rexx needs better list processing support is another question.
Btw, Awk has similar support for associative arrays as Rexx, but it
doesn't support lists explicitly. Perl has good support for both
associative arrays and lists.
Regards,
-anders <and...@lise.unit.no>
Dave Gomberg
><GOM...@UCSFVM.BITNET> writes:
>
>> Can someone please expand on the comment that REXX has poor support for
>> list processing? It seems to me it has nearly the best support of any
>
>satisfies points 1-3 above. However, there are several problems with
>this method:
>
> * It tend to be slow.
Doesn't this depend on the implementation and the use you make of the power?
I have never found variable access times to be a problem in any REXX I have
run.
> * It's sometimes a bit difficult to manipulate a list as a structure.
Again, depends on the bifs your implementation offers. I don't have a problem
in this area. Maybe you should try another implementation.
> * There is no simple way to handle _sublists_. I.e., concatenating
> two list, extracting parts of a list into an independant list, or
> reversing the order of a list (except for coding it as loops).
> * There is no "list" variables in Rexx, i.e. there is no way to
> assign the stem collection "foo." to the stem collection "bar."
See answer just preceeding.
I guess I still don't see the problem. Do you need sample code to see
how to do all this? Or ???
F. Scott Ophof
> However, for string manipulations that don't involve
>regexps, I find REXX easier to use than Perl. It might just be because I
>like a certain amount of verbosity.
(Steve, Ian, Anders, shall we ask Jack over for a beer and see how
verbose we can get him to be?) (grin)
>Pipes are available in some versions of REXX, with CMS Pipelines (and MVS
>Pipelines, which apparently exists but isn't talked about).
Come again? Pipes *IN* REXX? But..but..but.. _W_H_A_T_???
As far as I know (CMS, DOS, Unix), it's a command to the environment
which one issues, *not* a built-in, nor even an external function
package. I also fail to see what the concept of pipes (and for that
matter redirection) have to do with programming languages.
So has MVS seen the light too, at last? ;-)
>Being like C is not necessarily a good thing. Remember, most gods are not
>only powerful but also not subject to human understanding.
Since I class myself as a human, I'd have to classify even DOS'
batch language as a god (though not re power)...
Regards.
$$\
matthew green
>>j...@netcom.com (Jack F. Hamilton) writes:
>>: REXX does have most of the power of Perl, if you leave out regular
>>: expressions and forks/processes/pipes (which are operating system
>>: dependent).
>>
>>uh, perl wouldn't be anywhere near the god-like language it is with out
>>those above meantioned, brilliant features.. it becomes like C then..
>>hard to manipulate strings... ugh..
[ ... ]
>Being like C is not necessarily a good thing. Remember, most gods are not
>only powerful but also not subject to human understanding.
look again, i didn't say being like was was good, i said `ugh...' ;)
actually, there =are= cases i prefer to use C to perl for string
handling.. when i'm iterating of a string, a character at a time..
but i don't do that much, so its not a problem ;)
m..
Walt Sullivan
>list processing? It seems to me it has nearly the best support of any
>language (with the possible exception of awk) because of its associative
>memory. Dave
One thing that I REALLY wish REXX had was the ability to determine which
associative array indexes had been used (like Perl's keys() function). I'd also
like to be able to tell if a variable is defined or not (I regard:
SIGNAL OFF NOVALUE
IF foo = "FOO" THEN
SAY "foo is undefined"
SIGNAL ON NOVALUE
as a kludge, ugly, and not working for stem variables.)
I'd also like a Perl-like symbolic debugger that will let me say "continue
until you reach line 972 (Perl-debugger-speak for this is "c 972"), rather
than REXX's "trace" command where I have to single step through every
instruction (including the loop reading the 10,000 line file) before I get to
line 972. I suppose I could alter the source to turn on tracing after line 971,
but Perl lets me invoke the script with debug on by "perl -d scriptname".
I've also used most of the Perl functions mentioned in message
<1993Jun12.1...@netlabs.com> from Larry Wall:
> Stem variables can't be shifted or spliced (at least not
> efficiently). Data queues, er, that is, THE data queue, can't be
> subscripted or printed ("said") directly. The word() et al functions
> don't scale well, and presume that list elements will contain no spaces.
>
> In Perl any given list variable can be assigned, subscripted, pushed,
> popped, shifted, unshifted, sliced, spliced, packed, unpacked, split,
> joined, printed, reversed, sorted by arbitrary criteria, searched for
> subsets matching patterns, and passed to the operating system as a
> command. All of these operations are portable, efficient, and built-in.
--
Walt Sullivan wa...@orbit.ocunix.on.ca
Fido 1:163/109.4
None of what I say is what my employer says, ever!
Am I still confused if I'm not, but only THINK I'm confused?
Anders Christensen
> On Sun, 13 Jun 1993 05:15:05 LCL Anders Christensen said:
> <GOM...@UCSFVM.BITNET> writes:
>>
>>> Can someone please expand on the comment that REXX has poor support for
>>> list processing? It seems to me it has nearly the best support of any
>>
>> It's easy to see that this particular use of associative arrays
>> satisfies points 1-3 above. However, there are several problems with
>> this method:
>>
>> * It tend to be slow.
I mean: using associative arrays as lists tend to be slow compared to
using lists supported by the language.
> Doesn't this depend on the implementation and the use you make of
> the power? I have never found variable access times to be a problem
> in any REXX I have run.
Yes, but the interpreter still has to do a lot of unnecessary
bookeeping, since it can't really determine whether or not it was
necessary. On the other hand, a true list can only take integers as
subscripts, so the interpreter can optimize a great deal because of
that restriction. Consider:
'EXECIO' fn ft fm '(STEM FOO.'
do i=1 to foo.0
say foo.i
end
(The EXECIO syntax is probably wrong, sorry. It's been a long time
since I used it.) The interpreter can't really optimize anything. Even
though the _programmer_ know the only integer tails are used, this is
at best very hard for the _interpreter_ to figure out. So it can't
make any assumptions that would have enabled it to speed things up.
And even if you implement an analysis pass that _does_ understand
that, it only takes an interactive trace to make that analysis result
potentionally invalid.
Besides, the access time of _one_ variable hardly matters, but when
there are _many_ of them, it might have a significant impact on the
running time. Operations like inserting an element at the front of a
list in Rexx will be proportional to the number of elements in the
list, not _constant_ which it ought to be.
For example, Perl has associative arrays which are rather similar to
the ones in Rexx. Loading a file (/usr/dict/words) into an associative
array in Perl, the same way the 'lists' are used in Rexx:
( chop, $foo{++$index}=$_ ) while ( <STDIN> ) ;
$foo{0} = $index - 1 ;
takes approx 11.8 seconds of CPU time. While using lists in Perl in a
similar way:
( chop, push(@array,$_)) while ( <STDIN> ) ;
takes approx 3.8 seconds of CPU time. I think a similar speedup would
be possible in Rexx, wrt to list and associative arrays used as lists.
This may not really be a good argument for actually implementing lists
in Rexx, but it shows that associative arrays used as lists are much
slower than using 'true' lists directly; which was the statement in
question. Using Regina, the following solution:
do index=1 to lines('/usr/dict/words')
foo.index = linein('/usr/dict/words')
end
foo.0 = index - 1
takes 16.0 seconds of CPU time on the same machine and with
/usr/dict/words containing about 24,000 words. (It needs a fix to
avoid a bottleneck, so the version 0.05d uses about 45 seconds; this
will be fixed in version 0.05e of Regina.) Yes, I _know_ that the
EXECIO program can do this more efficiently, but that's not he point,
since: a) EXECIO is not standard Rexx, and b) EXECIO only loads the
data into variables, you'd still have to use loops to manipulate them.
Actually, the 'true' Perl way to do it would probably be just:
chop( @array = <STDIN> ) ;
Which takes approx 4.2 seconds CPU time. No doubt, Larry Wall can
come up with Perl versions that are both shorter and faster :-)
>> * It's sometimes a bit difficult to manipulate a list as a structure.
>
> Again, depends on the bifs your implementation offers. I don't have
> a problem in this area.
Good for you! May I ask _which_ bifs you are referring to. As far as I
know, there is no explicit support for list in TRL, and certainly no
bifs that support it. Note that when I say 'list', I mean associative
arrays having tails '1', '2', '3', ... and having tail '0' set to the
number of relevant tails.
> Maybe you should try another implementation.
No sarcasm, please.
> I guess I still don't see the problem. Do you need sample code to see
> how to do all this? Or ???
Yes, please. That would make the discussion a lot less academic. I've got
the impression that we are talking about different things.
Regards,
-anders
Anil Joshi
it for sometime. So, I am tossing it for your consideration.
I had been following the filename expansion by shell (In the REXXLIST),
REXX shell for unix and the list processing thread here.
Looks like if mapcar is implemented in rexx as a rexx native command
(not a bif), we can have the cake and eat it too..
I am assuming the following:
For all the unix commands/scripts/utilities the flags come before the filenames
The rexx shell r-e-p loop will be something like this.
Read the command
mapcar the command with all the flags onto the tokens that come after the flags
print RC from each application of the function on the argument
Those scripts/utilities/programs that expect a list would get a list of one and
still work.
Other scripts which never loop on their arguments ofcourse would work. List of
files in the current directory are expanded by unix globbing.
Thanks for your patience
Anil Joshi
jo...@cs.uiuc.edu
--
Sathsangatve nissangatvam From good company to no company
Nissangatve nirmohatvam From no company to lack of desire
Nirmohatve nischalatatvam From lack of desire to concentration of mind
Nischalatatve jeevanmuktihi From concentration of mind to liberation of life
Jeff Savit
Please, please do not turn REXX into a C clone. Programs are read much
more frequently than they are written, and a language's readability is
a key factor in its quality. To add type-promiscuity to REXX handling
of booleans would make the language less safe, and additionally would break
many existing REXX programs. The latter fact alone is enough to rule out
such a change.
I deplore the notion of switching to C-style type semantics.
Let's not copy a feature from one of the most type unsafe languages to REXX.
While we're at it, let's not be so hasty to change the semantics of "while" and
"until". You can argue like and dislike forever, but the existing behavior
is already in use in programs all over the world. I'm quite satisfied with
how REXX does this today, and I suspect that many people would object to having
their knowledge of this language construct be made obsolete along with their
programs.
I feel the same applies to grafting regular expressions into REXX. This
belongs as an external function call. I don't think I'm alone in finding
the proposed syntax very un-REXXlike. REXX isn't the Bourne shell either.
Backslash combined with a case-sensitive single character flags is exactly
the type of syntax I deliberately avoid by using REXX. Thank you, but I don't
want a language whose directives look like line noise. Regular expression
syntax is quite unnatural to the many of us for whom UNIX and C are not our
primary homes. Please don't assume it is generally accepted and universal.
The lack of useful redundancy (for error checking) in the name of terseness
is contrary to good software practice, especially for a language where ease of
use is a paramount concern. "Smallest number of characters" to express a
thought should also not be on our list. I also object to the notion that
REXX is verbose. COBOL is a verbose language; REXX hardly qualifies.
The fact that C or Perl has a language feature is not an endorsement for me.
The comment has been made that Algol was a superior language to many of the
'Algol-based' languages that succeeded it. I think a REXX incorporating these
changes would be inferior to Cowlishaw's REXX. REXX is a successful language
with many merits - among which are applicability for non-expert users and
readability, as well as a manageable style and sensible type semantics.
Let's not throw this away.
-- Every decade we're all forced to learn a Very Bad Language whose name begins
-- with the letter "C". Sometimes it's COBOL, sometimes it's C, sometimes
-- it's C++....
Dave Gomberg
I believe they are either planned or available for Personal REXX for DOS
and Windows as well.
What I mean by a list is something like:
Init: PROCEDURE EXPOSE List. /* Presume no null keys */
List.Head=''; List.Tail=''; RETURN
Add: PROCEDURE EXPOSE List.
PARSE ARG Key Dat /* Fancier if Key can be multiple words */
IF SYMBOL(List.Key.Data)='VAR' THEN RETURN 100 /* Duplicate add */
List.Key.Data=Dat; IF List.Tail='' THEN List.Tail=Key
List.Key.Higher=List.Head; Fix=List.Head; List.Fix.Lower=Key
List.Key.Lower=''; List.Head=Key; RETURN
Dropone: PROCEDURE EXPOSE List.
PARSE ARG Key
IF SYMBOL(List.Key.Higher)<>'VAR' THEN RETURN 100 /* Can't find entry */
H=List.Key.Higher; L=List.Key.Lower
IF H='' THEN List.Tail=L; ELSE List.H.Lower=L
IF L='' THEN List.Head=H; ELSE List.L.Higher=H
DROP List.Key.Lower; DROP List.Key.Higher; DROP List.Key.Data
RETURN
etc.
If you want, you can also access the list by key. If you have no natural
keys, use integers or ??? Dave
Eric Giguere
>Well, the bifs I was referring to are the ones for Personal REXX for OS/2.
Charles did indeed talk about his REXXLIB extensions to tail behaviour at
the last REXX Symposium. Much as we all know how you love Personal REXX,
I don't think any of us are ready to agree that such BIFs are a good long-term
solution to this problem. It would be a lot more efficient to have some of
this stuff as _part of the language definition_, and presumably the notation
would be more readable as well.
Of course, one of the things that has gotten lost in the REXX vs. Perl debate
is that REXX was deliberately designed to be a _small_ language. I don't
think Larry designed Perl to be large, but he did have different goals in
mind, that being primarily to have a language that did things he needed done,
things that involved lots of list processing and regular expressions.
In the short term, one of the things that would be nice from an API point of
view would be efficient ways of handling REXX "arrays" of the form stem.1 to
stem.n, where stem.0 is the count.
--
Eric Giguere gig...@csg.UWaterloo.CA
No, my dog's name is not "Rex".
F. Scott Ophof
>"F. Scott Ophof" <Op...@CS.UWINDSOR.CA> wrote:
>> Now take a language explicitely set-up to work with math,
>>and try to translate its syntax and mindset to that of REXX.
>One of REXX's strength's, in my opinion, is its arbitrary precision
>arithmetic. That's not common among general-purpose languages. Want pi to
>6000 decimal places? Easy enough. You just need lots of memory.
I am NOT contending *anything* in re the ARITHMETIC capabilities
of REXX. I repeat my dream-wish:
Now take a language explicitely set-up to work with higher MATH,
and try to rewrite it so its syntax and mindset become as easy
to READ and UNDERSTAND as that of REXX. AND to be able to read
a program years later and STILL understand it without frequent
referral to the manual. (dream on...) :-)
Regards.
$$\
Walt Sullivan
>I believe they are either planned or available for Personal REXX for DOS
>and Windows as well.
>
>What I mean by a list is something like:
>
>Init: PROCEDURE EXPOSE List. /* Presume no null keys */
>
>
>Dropone: PROCEDURE EXPOSE List.
>
>etc.
>
>If you want, you can also access the list by key. If you have no natural
>keys, use integers or ??? Dave
>
What if I need more than one list? Since your procedures refer to List
as a global symbol, I'd have to define a set of Init_x, Add_x, Dropone_x,
etc for EACH list! Or, I suppose, I could pass the name as a parameter,
build the appropriate command and INTERPRET it. Ugly!
Ian Collier
>I usually want to say "let me set a breakpoint whenever I get to
>this instruction and see what happens".
Then put "trace ?r" just before the instruction.
Or put a label there and say "trace ?l".
See, you have your choice with REXX trace.
> I need a real debugger, not interminable trace output
>that cannot even be easily redirected to a file (I'm sure that
>imc has already fixed this problem... :-)
I once saw an SF programme in which some people had special time-dilation
devices which allowed them to control the passage of time. I've always
wanted one of those! Now, if I had one then there would probably already be
a REXX/imc debugger available.
Alas, I live in the real world, and I'm struggling to keep up with life.
REXX/imc still isn't fully compatible with TRL2 yet.
However, I did recently amend all the trace output instructions (or all the
ones I could find - there are probably some more still in there :-) ) to
send the output to a variable file descriptor instead of to stdout.
Currently, that descriptor points to stderr (so you can send the trace to a
file with the Bourne shell command "rexx myprog myargs 2>tracefile"), but
I'm going to add an option and a commandline parameter to change it.
If you have two windows, you can say (on csh, to be different)
"(rexx myprog myargs > /dev/ttyp1) |& less" to view the output on another
window whilst paging through the trace output.
Ian Collier
Ian.C...@prg.ox.ac.uk | i...@ecs.ox.ac.uk
Dave Gomberg
EXPOSE (Listname.)
But I don't have the details in front of me. Useful for building things
that process stems (like sorts, etc.). Dave
W. J. Metzger
>
>I'd like to be able to tell if a variable is defined or not (I regard:
>
>SIGNAL OFF NOVALUE
>IF foo = "FOO" THEN
> SAY "foo is undefined"
>SIGNAL ON NOVALUE
>
>as a kludge, ugly, and not working for stem variables.)
>
returns VAR, LIT, or BAD. The following is excerpted from the help file:
Note: You should specify name as a literal string (or it should be derived
from an expression) to prevent substitution before it is passed to the
function.
Here are some examples:
/* following: Drop A.3; J=3 */
SYMBOL('J') -> 'VAR'
SYMBOL(J) -> 'LIT' /* has tested "3" */
SYMBOL('a.j') -> 'LIT' /* has tested A.3 */
SYMBOL(2) -> 'LIT' /* a constant symbol */
SYMBOL('*') -> 'BAD' /* not a valid symbol */
Ian Collier
> I'd also
>like to be able to tell if a variable is defined or not (I regard:
>SIGNAL OFF NOVALUE
>IF foo = "FOO" THEN
> SAY "foo is undefined"
>SIGNAL ON NOVALUE
>as a kludge, ugly, and not working for stem variables.)
Do you mean, like
if symbol("foo") == "LIT" then
say "foo is undefined"
?
>I'd also like a Perl-like symbolic debugger that will let me say "continue
>until you reach line 972 (Perl-debugger-speak for this is "c 972"), rather
>than REXX's "trace" command where I have to single step through every
>instruction (including the loop reading the 10,000 line file) before I get to
>line 972.
Try entering "trace -900" at the interactive trace prompt (this doesn't
yet work for the Unix interpreters, but it will appear in REXX/imc RSN).
The effect is to turn off all trace output until the point where it would
normally have paused for the 900th time. After that, tracing is turned back
on.
Admittedly it's not exactly a line number, but it is something. (Actually,
that would be quite a neat extension, wouldn't it? I mean, suppose that
instead of "trace -900" you entered "trace #973" then tracing would be
suppressed until line 973 was reached. Yes, I'll put that in...)
Ian Collier
Ian.C...@prg.ox.ac.uk | i...@ecs.ox.ac.uk
Ian Collier
>I am NOT contending *anything* in re the ARITHMETIC capabilities
>of REXX. I repeat my dream-wish:
> Now take a language explicitely set-up to work with higher MATH,
> and try to rewrite it so its syntax and mindset become as easy
> to READ and UNDERSTAND as that of REXX.
Which language are you thinking of? Why isn't REXX sufficient to be that
language?
You make a distinction between arithmetic and math. But I don't really see
why: you can write trig functions, complex number functions, etc. in Rexx.
Ian Collier
Ian.C...@prg.ox.ac.uk | i...@ecs.ox.ac.uk
Ian Collier
On Fri, 11 Jun 1993 09:42:48 -0400 Ian Collier said:
>>In various articles, Scott said:
>(OOPS!) (near-)duplicate postings?
Not necessarily, it's just that I pasted in several texts from two or more
articles...
>>S> Well, hexadecimal numbers are also valid "numbers" in REXX,
>>'Scuse me? I must have missed something here.
>I think I gave an example somewhere else. Anyway, try determining
>to which datatypes the following belongs:
> 14E6
>You should come up with at least Number and heXadecimal...
But it's also an alphanumeric string, or the name of a constant symbol.
Moreover, 101 is either a decimal, hex or binary number, or an alphanumeric
string, or the name of a constant symbol. "fed" is a word, or a hex number,
or it could be the name of a variable.
You shouldn't have any data such that you don't know where it came from or
what it is supposed to be. If you pulled it from the user, or read it from
a file, or received it as the result of a function, then you'd better make
sure that the user or the file or the function is able to specify what the
data means (or else always gives the data in the same format) because if not
then you are sunk. You might just as well ask for the name of a month and
have it returned in Hebrew.
>My point is that if you don't *know* which one it is, testing for
>its datatype can produce inconclusive results (which is indeed a
>valid reason for C's insistance on the datatype of an entity).
There is no such datatype as "a hex number" in C. It might be an integer,
or a floating point number, or a string. If your C program has to deal with
the characters "1E2", then that is a string, and you cannot convert it to a
number without knowing what it is supposed to be.
Ian Collier
Ian.C...@prg.ox.ac.uk | i...@ecs.ox.ac.uk
Edward T Spire
: >Wasn't the REXX compiler already available when that shuttle blew
: >up some time ago? (grin)
: Nope - that was 1986; SAA did't even exist yet, so there was no REXX
: on MVS - I was stuck with TSO CLIST. Anyway, the Challenger
: disaster was a hardware problem (faulty O-rings).
...and who says what kind of software they were using when they did the
design work? Morton Thiokol is a DYNAPLAN customer (our mainframe
spreadhseet). Now I doubt anybody would use something as mundane as a
spreadsheet for such serious applications, but it did give me at least
one nightmare.
--
========================================================================
===== "The heart must mediate between the brain and the hands" =====
Ed Spire e...@wrkgrp.com (on uunet)
Edward T Spire
: In Perl any given list variable can be assigned, subscripted, pushed,
: popped, shifted, unshifted, sliced, spliced, packed, unpacked, split,
: joined, printed, reversed, sorted by arbitrary criteria, searched for
: subsets matching patterns, and passed to the operating system as a
: command. All of these operations are portable, efficient, and built-in.
: What's worse, these operations are *necessary*. When you don't have
: them, you end up re-inventing them over and over, sometimes wrong.
Larry, my first thought was that you must live in a more complicated
world than most of us.
But, no, you live in the same world as me. Maybe you just see the world
differently.
Seriously, I have always found that it was easier for me to whip up
what I needed when I needed it than to try and learn and remember how
to use all that stuff you have up there.
Edward T Spire
: This may be going off in a tangent a little bit..but I had been mulling over
: it for sometime. So, I am tossing it for your consideration.
: I had been following the filename expansion by shell (In the REXXLIST),
: REXX shell for unix and the list processing thread here.
: Looks like if mapcar is implemented in rexx as a rexx native command
: (not a bif), we can have the cake and eat it too..
: I am assuming the following:
: For all the unix commands/scripts/utilities the flags come before the filenames
: The rexx shell r-e-p loop will be something like this.
: Read the command
: mapcar the command with all the flags onto the tokens that come after the flags
: print RC from each application of the function on the argument
: Those scripts/utilities/programs that expect a list would get a list of one and
: still work.
: Other scripts which never loop on their arguments ofcourse would work. List of
: files in the current directory are expanded by unix globbing.
Haven't you guys at U of I figured out yet that the brown acid is bad?
Seriously, I haven't the slightest idea what you are talking about.
I looked in the AIX/3 doc, no mention of rapcar. I asked my local
unix guru, he'd never heard of it. And I can't make heads nor tails
out of this posting.
Please enlighten us!
Larry Wall
: In article <1993Jun12.1...@netlabs.com> lw...@netlabs.com (Larry Wall) writes:
:
: > popped, shifted, unshifted, sliced, spliced, packed, unpacked, split,
: > joined, printed, reversed, sorted by arbitrary criteria, searched for
: > subsets matching patterns, and passed to the operating system as a
: > command. All of these operations are portable, efficient, and built-in.
:
Rhetoric has to be good for something. Why not Perl?
Larry Wall
lw...@netlabs.com
Larry Wall
: The fact that C or Perl has a language feature is not an endorsement for me.
That does not, of course, assert anything about either the inverse or
the converse.
: The comment has been made that Algol was a superior language to many of the
: 'Algol-based' languages that succeeded it.
If Algol was a superior language, then people obviously prefer inferior
languages.
: I think a REXX incorporating these changes would be inferior to
: Cowlishaw's REXX.
See above.
: REXX is a successful language with many merits - among which are
: applicability for non-expert users and readability, as well as a
: manageable style and sensible type semantics. Let's not throw this
: away.
Let's not confuse success with superiority, or vice versa.
:-)
Larry
Anil Joshi
>Haven't you guys at U of I figured out yet that the brown acid is bad?
What is brown acid?
>Seriously, I haven't the slightest idea what you are talking about.
>I looked in the AIX/3 doc, no mention of rapcar. I asked my local
>unix guru, he'd never heard of it. And I can't make heads nor tails
>out of this posting.
Who ever said it is part of Unix? The idea is from Lisp - that's where you
look for how it works.
I am suggesting that something like "mapcar" of Lisp if implemented as part
of a shell would be very useful (and while everybody is brain-storming on the
rexx shell, I just wanted to throw it into the pot).
Let me see if I can explain how the mapcar in lisp works.
(mapcar add1 '(1 2 3))
will return
(2 3 4)
where add1 is a function that uis defined to take a number as an argument and
add 1 to it and return the resulting value.
mapcar executes add1 with each of the list elements in turn. So the above is
equivalent to the following procedural code:
for i = 1 to 3 do
print add1(i)
end
>Please enlighten us!
>--
I hope the above helps....
F. Scott Ophof
>: >In various articles, Scott said:
>: >S>I'd like to see an example of what you mean.
>Just to clear up a little misconception here, it was only being claimed
>that the brackets are required in Perl. The REXX code was just an example.
OK, so an example of a "dangling" THEN is:
if condition then something
whereas in:
if condition then { something }
the THEN does not "dangle"?
If so, then I'll revise my def. of "dangling" to be otherwise than
the dictionary, where programming languages are concerned.
(I replaced the leading spaces below with underscores to ensure that
whatever TAB-setting you have, you'll see what * I* see (I never use
tabs).)
>By the way, I'd write the C code above as:
>________if (foo) {
>________________while (bar()) {
>________________________if (x == 3)
>________________________________printf("X was 3!\n");
>________________________else
>________________________________printf("X wasn't 3!\n");
>________________}
>________}
>________else
>________________blurfl();
Purely from the readability angle as seen from what I feel to be the
REXX mindset, it just isn't.
In a general sense, if what you see above is what you EXPECT to see,
then the eye-movement needed to read that makes it rather tiring
(for me). This has nothing to do with any programming language it
itself, but is pure ergonomics. However, ergonomics *is* important
in programming languages.
But this is a side track, and I'd better stop it after showing what
*I* would feel to be a readable & understandable format:
___If (foo) {
_____While (bar()) {
_______If (x == 3) printf("X was 3!\n");
_______Else printf("X wasn't 3!\n");
_______}
_____}
___Else blurfl();
Please note:
- Closing curlies under the first char of the last statement of
a block.
- Indentation of 2.
- The "then" part on the "IF" line.
- "Else" lined up with "IF".
- Capitalisation of instructions when starting a "sentence" or
block.
Partly personal, but mainly done for grouping of related stuff.
>(My rule of thumb being that any statement longer than a line gets
>bracketed, whether it needs it syntactically or not.)
For it seems the same reason I always have an ELSE with every
"IF.. THEN.." (even if it's an "ELSE NOP"); safety.
Regards.
$$\
Edward T Spire
: Try entering "trace -900" at the interactive trace prompt (this doesn't
: yet work for the Unix interpreters, but it will appear in REXX/imc RSN).
What do you mean, Ian, when you say that "this doesn't work yet for the
Unix interpreters"?
It works just fine in uni-REXX, the **real** Unix interpreter ;-)
Edward T Spire
: e...@wrkgrp.COM (Edward T Spire) writes:
: >Haven't you guys at U of I figured out yet that the brown acid is bad?
: What is brown acid?
Obviously your not old enough to have been a hippie (at least not in
the first wave...) :-)
: >Please enlighten us!
: >--
: I hope the above helps....
Yes, it did. Thanks a lot.
Ian Collier
>___If (foo) {
>_____While (bar()) {
>_______If (x == 3) printf("X was 3!\n");
>_______Else printf("X wasn't 3!\n");
>_______}
>_____}
>___Else blurfl();
>Please note:
> - Closing curlies under the first char of the last statement of
> a block.
Hey! Where are the indentation police? No-one writes C like that! :-)
[No-one should write Rexx like that either. That is my opinion. It also
seems to be the opinion of the "majority" of Rexx programmers as far as I am
aware. It's not worth an argument, but I couldn't resist putting that in
after the goings-on at the Symposium].
> - Indentation of 2.
Not enough... try 3. :-)
> - Capitalisation of instructions when starting a "sentence" or
> block.
Sorry, but C is case-dependent. "Else" does not mean "else" - it is the
name of a variable.
Oh no... I've perpetuated the style war! :-(
Ian Collier
Ian.C...@prg.ox.ac.uk | i...@ecs.ox.ac.uk
Ian Collier
>What if I need more than one list?
Then name the lists like this: list.mylist.* list.yourlist.* list.foo.*
Pass the name "mylist", "yourlist" or "foo" to the functions as a parameter,
and everything's fine. No need to use interpret.
Ian Collier
Ian.C...@prg.ox.ac.uk | i...@ecs.ox.ac.uk
Ian Collier
>Ian Collier (i...@comlab.ox.ac.uk) wrote:
>: Try entering "trace -900" at the interactive trace prompt (this doesn't
>: yet work for the Unix interpreters, but it will appear in REXX/imc RSN).
>What do you mean, Ian, when you say that "this doesn't work yet for the
>Unix interpreters"?
Sorry, I appear to have a word out. That should have been "free Unix
interpreters".
Ian Collier
Ian.C...@prg.ox.ac.uk | i...@ecs.ox.ac.uk
Michael Cook
>Seriously, I have always found that it was easier for me to whip up
>what I needed when I needed it than to try and learn and remember how
>to use all that stuff you have up there.
You haven't been programming for very long, have you.
M.
Jeff Savit
><TXJ...@VMETH3.OSSD.GIS.ML.COM> writes:
>: The fact that C or Perl has a language feature is not an endorsement for me.
>>That does not, of course, assert anything about either the inverse or
>>the converse.
>>: The comment has been made that Algol was a superior language to many of the
>: 'Algol-based' languages that succeeded it.
>
>>If Algol was a superior language, then people obviously prefer inferior
>>languages.
They often do, sad to say. Has anybody heard of COBOL and FORTRAN?
I feel the same about C. The floor is open to speculation on why
inferior languages (or languages we loftily deem inferior) do so well.
>: I think a REXX incorporating these changes would be inferior to
>: Cowlishaw's REXX.
>>See above.
Okay.
>: REXX is a successful language with many merits - among which are
>: applicability for non-expert users and readability, as well as a
>: manageable style and sensible type semantics. Let's not throw this
>: away.
>>Let's not confuse success with superiority, or vice versa.
I agree, and consider REXX both superior and successful, and would be
glad to see it made even better and more widely used. Let's therefore
discuss ways to improve REXX and increase its acceptance. In my
opinion, making it a clone of less-accessable (however powerful)
languages would detract from the qualities that make it so attractive.
What substantive improvements to the language can be made without
reducing the properties I cite above? Please, lets avoid feature-envy
or the featureitis disease: the philosophy of "language X has feature Y
therefore include it" is not a good design principle (see PL/I).
F. Scott Ophof
>In article <930614.15...@MReXX-0.18>, "F. Scott Ophof"
><Op...@CS.UWINDSOR.CA> wrote:
>>Please note:
>> - Closing curlies under the first char of the last statement of
>> a block.
>Hey! Where are the indentation police? No-one writes C like that! :-)
(hehehe) Remember, it's the way *I* would write it so that *I* can
read it easily. How others do it is up to them of course. Except
where programs need to be exchanged between programmers (or the need
might arise).
>Oh no... I've perpetuated the style war! :-(
Actually, I was curious why those curlies in Larry's example aren't
lined up. It at least doesn't seem obvious to me. But it's C, and
I'm not really that interested. Just idle curiosity.
Regards.
$$\
F. Scott Ophof
>In article <930613.15...@MReXX-0.18>, "F. Scott Ophof"
><Op...@CS.UWINDSOR.CA> wrote:
>> Now take a language explicitely set-up to work with higher MATH,
>> and try to rewrite it so its syntax and mindset become as easy
>> to READ and UNDERSTAND as that of REXX.
>Which language are you thinking of? Why isn't REXX sufficient to be that
>language?
I was not thinking of any specific language.
REXX the language _IN ITSELF_ and REXX the package _AS DELIVERED_
by the implementors is not sufficient to be labeled "explicitely
set-up as a HIGHER-MATH language"; it has neither the requisite
built-ins, nor an external function package to that effect.
(Advert/Note: REXX/imc and BREXX could be termed exceptions in the
math func-pkg aspect.) ;-)
Anyway, REXX is not _DESIGNED_ to be a higher-math language, though
I wouldn't be surprised in the least if with standardized external
func-packs it could become such.
But then that also goes for ext-func-packs for spreadsheet work,
desktop-publishing, CAD, etc...
>You make a distinction between arithmetic and math. But I don't really see
>why: you can write trig functions, complex number functions, etc. in Rexx.
Steve already answered this, and I agree with him in general.
In general, if there is any functionality REALLY missing that is
useful to all users who would use REXX anyway, then its inclusion
should be seriously considered. If it's only useful to a (small)
subset, then an external func-pack should suffice.
But at or near top-of-list right now would seem to be de-RAFing of
the language (where possible).
Regards.
$$\
F. Scott Ophof
> Just let me add my voice to Jeff's plea NOT to make REXX more
>"C" like. Unix and C are not nearly the universal role models that
>many academicians think they are (or should be ;->). REXX is hughly
>popular because it attempts to communicate with its users and the USER's
>terms, not the computer's.
That is why I keep hammering on relegating stuff to EXTERNAL
FUNCTION PACKAGES. Same re meaning of a comment (as far as the USER
is concerned, it just ain't there, so my vote still goes to Chip's
definition).
REXX is used by normal HUMANS who do not necessarily need to have
an exotic/esoteric/higher educational background. Nothing derogatory
intended re either group, just stressing the *AVERAGE* part.
To semi-quote an offlist response, REXX is a first step on the way
to the simple human-to-computer communication in Star Trek.
Regards.
$$\
Walt Sullivan
>On Sun, 13 Jun 1993 01:04:48 EST Walt Sullivan said:
>>
>>I'd like to be able to tell if a variable is defined or not (I regard:
>>
>>SIGNAL OFF NOVALUE
>>IF foo = "FOO" THEN
>> SAY "foo is undefined"
>>SIGNAL ON NOVALUE
>>
>>as a kludge, ugly, and not working for stem variables.)
>>
> At least in the CMS implementation you have the Symbol function which
>returns VAR, LIT, or BAD. The following is excerpted from the help file:
>
So does ARexx (blush). I should RTFM.
Ian Collier
>Besides, the access time of _one_ variable hardly matters, but when
>there are _many_ of them, it might have a significant impact on the
>running time. Operations like inserting an element at the front of a
>list in Rexx will be proportional to the number of elements in the
>list, not _constant_ which it ought to be.
I'm surprised no-one has said it yet, so I might as well make the trite
observation that there are plenty of list processing operators you can use
as long as your items do not contain spaces [*]...
interpret "a=charin('/usr/dict/words',,chars('/usr/dict/words'));"\
"a=translate(a,' ','a'x);say words(a)"
25144
0.5 user 0.3 system 0:01 elapsed
Much quicker than any of the other programs you demonstrated. :-) [this is a
Sparc 2, by the way]. Oh yes, and 25144 *is* the same output as "wc -l
/usr/dict/words". :-)
[*] If you can find another character which isn't used, you can always
translate the spaces to it before storing the items, and translate back
after retrieval.
Ian Collier
Ian.C...@prg.ox.ac.uk | i...@ecs.ox.ac.uk
Ian Collier
>REXX the language _IN ITSELF_ and REXX the package _AS DELIVERED_
>by the implementors is not sufficient to be labeled "explicitely
>set-up as a HIGHER-MATH language"; it has neither the requisite
>built-ins, nor an external function package to that effect.
>(Advert/Note: REXX/imc and BREXX could be termed exceptions in the
>math func-pkg aspect.) ;-)
But "The Original REXX" comes with a math function package too, so I
consider it a duty to supply a math package with my interpreter (which,
incidentally, has the same function names as RXMATHFN MODULE as far as I
remember). :-)
Ian Collier
Ian.C...@prg.ox.ac.uk | i...@ecs.ox.ac.uk
Dave Gomberg
>On Mon, 14 Jun 1993 12:46:12 -0400 Ian Collier said:
>><Op...@CS.UWINDSOR.CA> wrote:
>REXX the language _IN ITSELF_ and REXX the package _AS DELIVERED_
>by the implementors is not sufficient to be labeled "explicitely
>set-up as a HIGHER-MATH language"; it has neither the requisite
>built-ins, nor an external function package to that effect.
>
>(Advert/Note: REXX/imc and BREXX could be termed exceptions in the
>math func-pkg aspect.) ;-)
So could Personal REXX. For a copy of the new Personal REXX newsletter,
Acorn, write:
Quercus Systems, Box 2157, Saratoga CA 95070
Voice 408-867-7399, BBS 408-867-7488, Fax 408-867-7489
CompuServe GO QUERCUS, MCI Mail 394-6200, Internet 75300...@Compuserve.com
Products:
Personal REXX for DOS, Windows, OS/2
REXXTERM (Terminal simulator with REXX macro language support)
Programming in REXX by Daney, McGraw-Hill
Gary Benson
>: In Perl any given list variable can be assigned, subscripted, pushed,
>: popped, shifted, unshifted, sliced, spliced, packed, unpacked, split,
>: joined, printed, reversed, sorted by arbitrary criteria, searched for
>: subsets matching patterns, and passed to the operating system as a
>: command.
It slices, it dices, it even juliennes fries!
--
Gary Benson-_-_-_-_...@sisu.fluke.com_-_-_-_-_-_-_-_-_-_-_-_-_-_-
Freedom is just chaos with better lighting. -Alan Dean Foster
Edward T Spire
25 years, in 8 languages, on 5 platforms, for all kinds of commercial
concerns.
Remember, I was only talking about Rexx coding experience in the above
statement. Rexx coding is often quite different from the kind of
coding that I would have done in Fortran, 370 assembler, PL/1,
or C.
========================================================================
===== "The heart must mediate between the brain and the hands" =====
Ed Spire e...@wrkgrp.com (on uunet)
The Workstation Group 708-696-0255 fax: 708-696-4800
Larry Wall
: >Oh no... I've perpetuated the style war! :-(
It needn't be a style war, as long as we realize that different people
optimize for different psychological needs.
: Actually, I was curious why those curlies in Larry's example aren't
: lined up. It at least doesn't seem obvious to me. But it's C, and
: I'm not really that interested. Just idle curiosity.
In my case, they don't line up for several reasons. It tends to save
precious screen real estate when you "nestle" the initial curly. It's
the One True Bracketing Style, according to Dennis Ritchie and friends.
But in particular, when I'm looking at the end of a block and want to
find its beginning, I'm not actually interested in where the other
curly is, I'm more interested in the keyword controlling the block, whether
it's "for" or "while" or "if" or "switch" or whatever. My eye travels
straight up from the closing curly to the keyword. There's no need
to see an intervening opening curly--it just gets in the way.
In the rare event that I actually want to find the opening curly, I just
bounce on the % key in vi, which goes to the opposite curly or paren.
But this does not happen often, because I think of
while ($whatever) {
# some code
}
as a single syntactic construct, not as a condition followed by a block.
Some people line up the closing curly with the statements it contains.
I don't, because I like to see things terminated consistently. An
"outdented" curly accomplishes this. An indented curly tends to
disappear from view, forcing the block to be visually terminated by the
next statement, which could be almost anything. That is, with
while ($whatever) {
# some code
}
$foo = $bar;
I don't have to worry about what sort of thing $foo is, but with
while ($whatever) {
# some code
}
$foo = $bar;
I would, and I don't like to worry about things like that.
What's worse, there are occasional reasons to outdent a portion of a
statement that aren't related to block termination. In Perl, for
instance, there is a line-delimited quote mechanism:
while ($whatever) {
# some code
print <<"END_OF_TEXT";
MAT 6:7 But when ye pray, use not vain repetitions, as the heathen do: for
they think that they shall be heard for their much speaking.
END_OF_TEXT
# more code
}
Similar situations sometimes arise in C, if you're conscientious about
keeping your lines within 80 columns. Since I expect my block to be
terminated with a curly that lines up with the while, I don't see the
embedded text as control structure. Those who rely solely on indentation
to perceive control structure will be more confused in such situations.
This is all related to the reason I said I don't like "dangling"
statements. I don't think you need to revise your lexicon, Scott. The
basic meaning of "dangling" is that something isn't well anchored at
one end, and is free to flap about in the breeze. To me, that closing
curly is a fixed anchor, perceptually speaking. A dangling statement
to my mind is one whose termination is defined not by the presence of
something, but by the absence of something, namely the absence of any
more of the first statement!
Anyway, that's how I think. I don't expect other people to think like I do.
Larry
F. Scott Ophof
>e...@wrkgrp.COM (Edward T Spire) writes:
>>Seriously, I have always found that it was easier for me to whip up
>>what I needed when I needed it than to try and learn and remember how
>>to use all that stuff you have up there.
>You haven't been programming for very long, have you.
I suppose this depends on how you define "programming".
Using the word in the sense of "coding" (ie. translating thoughts to
some more-or-less arcane set of character-sequences), I dunno. Ed?
But if you mean it in the sense of "*writing* a program" (writing
down ones thoughts, doing a bit of retouching here and there to make
it formally correct REXX), and given the fact that REXX is only ten
years old (for the general public) this year, heck, you could even
turn out to be right!
But then I wouldn't know really; I happily turned my back on coding
around '83, and started writing in REXX.
Regards.
$$\
F. Scott Ophof
>But "The Original REXX" comes with a math function package too, so I
>consider it a duty to supply a math package with my interpreter (which,
>incidentally, has the same function names as RXMATHFN MODULE as far as I
>remember). :-)
This is a surprise. Could you enlighten me? I remember an RXSYSFN
MODULE, but no RXMATHFN MODULE. Which CMS version?
For the record, that REXX/imc comes with a math set as ext-func-pack
is a definite bonus, imho!
Regards.
$$\
Ian Collier
>This is a surprise. Could you enlighten me? I remember an RXSYSFN
>MODULE, but no RXMATHFN MODULE. Which CMS version?
If I remember correctly, back in 1987 when I worked at IBM using a CMS 3
system, there were RXMATHFN, RXSYSFN, RXUSERFN and RXLOCFN modules. Surely
these weren't local extensions?...
RXMATHFN contained sin, cos, tan, asin, acos, atan, exp, ln, topower and
sqrt. (There may have been others that I've forgotten).
While we're on higher math, I wrote a module which did Gaussian integration
of an expression between two numeric limits - but I think that's been lost,
unfortunately.
Ian Collier
Ian.C...@prg.ox.ac.uk | i...@ecs.ox.ac.uk
Ian Collier
>In my case, they don't line up for several reasons. It tends to save
>precious screen real estate when you "nestle" the initial curly. It's
>the One True Bracketing Style, according to Dennis Ritchie and friends.
Amen to that! :-)
There are two other reasons for writing code this way, both concerned with
my present choice of editor - jove (for which, unfortunately, there's no
REXX mode).
1. When I type '}' it lines it up under the first non-blank character in
the line which contains the matching '{'.
2. If the matching '{' is off the screen when I type '}', the line
containing the '{' is written in the message line at the bottom of the
screen. It's much more helpful to see "while (whatever) {" rather than
just "{".
Unfortunately, these do not apply to Rexx code. However, several of Larry's
other reasons do...
Ian Collier
Ian.C...@prg.ox.ac.uk | i...@ecs.ox.ac.uk
F. Scott Ophof
>In article <930615.13...@MReXX-0.18> Scott Ophof said:
>: Ian Collier said:
>: >Oh no... I've perpetuated the style war! :-(
>It needn't be a style war, as long as we realize that different people
>optimize for different psychological needs.
Right. :-)
>: Actually, I was curious why those curlies in Larry's example aren't
>: lined up. It at least doesn't seem obvious to me. But it's C, and
>In my case, they don't line up for several reasons. It tends to save
>precious screen real estate when you "nestle" the initial curly. It's
Actually I meant "lined up with respect to each other", but that's
irrelevant after your explanation. Thanks.
>But this does not happen often, because I think of
> while ($whatever) {
> # some code
> }
>as a single syntactic construct, not as a condition followed by a block.
In REXX comparable to:
If condition then do
/* Whatever */
End
Else do
/* Something else */
End
The only thing here is that the ELSE and END of THEN get in the way
of seeing the whole construct.
The following would keep the separate blocks neatly visible, but
one still can't see the start of the IF from the end of the ELSE.
If condition
then do
/* Whatever */
End
Else do
/* Something else */
End
And the following? Erm...
If condition
then do
/* Whatever */
End
Else do
/* Something else */
End
So I prefer the following, as a "look-back" in two stages (from END
of ELSE to the ELSE itself, and from there to the IF).
If condition then do
/* Whatever */
End
Else do
/* Something else */
End
>An indented curly tends to
>disappear from view, forcing the block to be visually terminated by the
>next statement, which could be almost anything.
>...
>What's worse, there are occasional reasons to outdent a portion of a
>statement that aren't related to block termination. In Perl, for
>instance, there is a line-delimited quote mechanism:
> while ($whatever) {
> # some code
> print <<"END_OF_TEXT";
>MAT 6:7 But when ye pray, use not vain repetitions, as the heathen do: for
> they think that they shall be heard for their much speaking.
>END_OF_TEXT
> # more code
> }
As far as I know this is not a problem in REXX, due to its syntax.
At least I haven't run into it, but then I don't have the years of
intensive programming many others have had.
> A dangling statement
>to my mind is one whose termination is defined not by the presence of
>something, but by the absence of something, namely the absence of any
>more of the first statement!
In other words, you'd be missing the full-stop at the end of a
sentence (to use the UK-English term for "period"). Yes, I can
see that now.
And now I understand that I've been missing the concept of a general
full-stop in all programming languages, something just as optically
visible as the period in normal written/typed text.
I don't see the colon as such in REXX; it doesn't have the quality
of visibility that the period has in text. But then no character I
can think of could fulfill that function in REXX, or in any other
language I know (Disclaimers: I don't know *that* many, nor have I
spent much time thinking about full-stops).
Regards.
$$\
Lezz Giles
|>Xref: merlin.dev.cdx.mot.com comp.lang.rexx:2178 comp.lang.perl:8410
|>Newsgroups: comp.lang.rexx,comp.lang.perl
|>Path: merlin.dev.cdx.mot.com!isunix.cdx.mot.com!mothost!binford!att!linac!uwm.edu!cs.utexas.edu!usc!howland.reston.ans.net!noc.near.net!uunet!wrkgrp!ets
|>From: e...@wrkgrp.COM (Edward T Spire)
|>Subject: Re: REXX and (NOT versus!) Perl
|>Message-ID: <1993Jun16.1...@wrkgrp.COM>
|>Followup-To: comp.lang.rexx,comp.lang.perl
|>Organization: The Workstation Group
|>X-Newsreader: TIN [version 1.2 PL0]
|>References: <jfhC8E...@netcom.com> <1993Jun11.0...@netlabs.com> <1993Jun11.2...@evtech.com> <1993Jun12.1...@netlabs.com> <1993Jun14....@wrkgrp.COM> <mcook.7...@fendahl.dev.cdx.mot.com>
|>Date: Wed, 16 Jun 93 12:32:22 GMT-0:05
|>Lines: 26
|>
|>Michael Cook (mc...@fendahl.dev.cdx.mot.com) wrote:
|>: e...@wrkgrp.COM (Edward T Spire) writes:
|>
|>: >Seriously, I have always found that it was easier for me to whip up
|>: >what I needed when I needed it than to try and learn and remember how
|>: >to use all that stuff you have up there.
|>
|>: You haven't been programming for very long, have you.
|>
|>25 years, in 8 languages, on 5 platforms, for all kinds of commercial
|>concerns.
|>
|>Remember, I was only talking about Rexx coding experience in the above
|>statement. Rexx coding is often quite different from the kind of
|>coding that I would have done in Fortran, 370 assembler, PL/1,
|>or C.
I don't understand your point - if you don't want to use simple perl
list operations but instead prefer to work out your own algorithms, then
presumably when you program in C you don't use the stdio functions in C but
instead write your own formatted output functions?
When you program in perl the list operations are part of the language and you
don't even need to think about what they are or what they do - you just use
them! I've not used REXX but it sounds like it is a lower-level language
with a lot fewer features.
Lezz
Stephen E. Bacher
>full-stop in all programming languages, something just as optically
>visible as the period in normal written/typed text.
There *is* such a language... COBOL!
In COBOL you group things like this:
IF A = 1 THEN ADD 1 TO FOO PERFORM BAR MOVE 'X' TO BAZ.
IF B = 2 THEN ADD 2 TO FOO. PERFORM FROB. MOVE 'Y' TO MUMBLE.
Note that in the above code fragment FROB will always be performed
and 'Y' will always be moved to MUMBLE, regardless of the outcomes
of the IF-conditions.
If you consider the period (or full stop) "visible", COBOL will soon
disabuse you of that notion. (We really like this word all of a
sudden over here.)
In fact, supposedly it was a period rendered invisible by being coded
in column 73, one of those "illegal" columns in COBOL, that caused some
insurance-billing disaster or something comparable to shuttle blowups
in the so-called "real world", according to computer legend.
- seb
Robert Losee
>In COBOL you group things like this:
> IF A = 1 THEN ADD 1 TO FOO PERFORM BAR MOVE 'X' TO BAZ.
> IF B = 2 THEN ADD 2 TO FOO. PERFORM FROB. MOVE 'Y' TO MUMBLE.
>Note that in the above code fragment FROB will always be performed
>and 'Y' will always be moved to MUMBLE, regardless of the outcomes
>of the IF-conditions.
>If you consider the period (or full stop) "visible", COBOL will soon
>disabuse you of that notion. (We really like this word all of a
>sudden over here.)
>In fact, supposedly it was a period rendered invisible by being coded
>in column 73, one of those "illegal" columns in COBOL, that caused some
>insurance-billing disaster or something comparable to shuttle blowups
>in the so-called "real world", according to computer legend.
I had an advanced COBOL course that had a little example of
programming errors. You had an output and had to figure out what
things were wrong. One thing that very few people got within the
time limit was the period in column 73. It looked ok and you had to
take a ruler or count to 73 to realize it was wrong. Anyway after
that I treated the period as though it was a command, and placed it
on its own line (indented appropriately). Looks weird but it
highlighted it as a control feature. Still I was greatly releaved
when the new COBOL standard added the "END" features.
In any case I think the "END"s are a much better way to go.
--
*-------------------------------------------------------------------------*
Robert D. Losee BITNET: ucas402@unlvm
326 Adminstration Bldg Internet: rlo...@unlinfo.unl.edu
University of Nebraska Phone: (402) 472-7663
Ian Phillipps
>In article <JSC.93Ju...@monolith.mit.edu> j...@monolith.mit.edu (Jin S Choi) writes:
>: In article <1993Jun12.1...@netlabs.com> lw...@netlabs.com (Larry Wall) writes:
>: > In Perl any given list variable can be assigned, subscripted, pushed,
>: > popped, shifted, unshifted, sliced, spliced, packed, unpacked, split,
>: > joined, printed, reversed, sorted by arbitrary criteria, searched for
>: > subsets matching patterns, and passed to the operating system as a
>: > command. All of these operations are portable, efficient, and built-in.
>: It's rather impressive, to hear them enumerated like that.
>Rhetoric has to be good for something. Why not Perl?
I think you forgot stapled, folded, spindled and mutilated. Or are they
additions in Perl 5? ;-)
print sort { "l" lt "m"; } split(//,"Just another Perl mutilator")
(BTW - I was quite surprised at what happened when I ran the above)
--
Ian Phillipps, Unipalm Ltd, 216 Science Park, Phone +44 223 250100
Milton Road, Cambridge, CB4 4WA, England. Phax +44 223 250101
PIPEX Ltd. is a wholly-owned subsidiary of Unipalm Ltd. - phone 0223 250120
Andrew Zaitsev
>arithmetic. That's not common among general-purpose languages. Want pi to
>6000 decimal places? Easy enough. You just need lots of memory.
The only limit to REXX is available memory.
I used to have a CMS REXX program that reads contents of
virtual memory into variable and then searches it for a substring.
The variable was 1 megabyte long!
Michael Bernstein
print sort { "l" lt "m"; } split(//,"Just another Perl mutilator")
(BTW - I was quite surprised at what happened when I ran the above)
So was I:
>perl
print sort { "l" lt "m"; } split(//,"Just another Perl mutilator")
;
Segmentation fault (core dumped)
Jack F. Hamilton
>When you program in perl the list operations are part of the language and you
>don't even need to think about what they are or what they do - you just use
>them! I've not used REXX but it sounds like it is a lower-level language
>with a lot fewer features.
No, it's more like a different tool for a different job.
Both REXX and Perl have ardent defenders, and many people like both. I
wonder how many people are fans of both Perl and COBOL...
--
------------------------------------------------------------------------
Jack Hamilton j...@netcom.com kd6ttl@n0ary.#nocal.ca.us.na (AMPR)
Post Office Box Box 281107 San Francisco, California 94128 USA
F. Scott Ophof
>In COBOL you group things like this:
> IF A = 1 THEN ADD 1 TO FOO PERFORM BAR MOVE 'X' TO BAZ.
> IF B = 2 THEN ADD 2 TO FOO. PERFORM FROB. MOVE 'Y' TO MUMBLE.
>Note that in the above code fragment FROB will always be performed
>and 'Y' will always be moved to MUMBLE, regardless of the outcomes
>of the IF-conditions.
>If you consider the period (or full stop) "visible", COBOL will soon
>disabuse you of that notion. (We really like this word all of a
>sudden over here.)
I could get used to the idea, especially if lowercase is normal.
But in REXX one would have problems of course:
If something then stem.
= whatever, else say "Go home Yankee!".
Is the period after "stem" a full-stop, or the dot of a stem-name?
If taken as a full-stop, then "= whatever" triggers an error-msg.
So continuation lines should then be the default, of course.
And the comma? Could that be used the same way as in human
languages? How about:
If something = then, then stem. = whatever else,
else say "Hurrah Braves!".
to ensure that the _second_ THEN and ELSE are the keywords?
Would PARSE, functions and CALL still work as-is?
Regards.
$$\
Chris Thompson
The minimal example seems to be
@x = sort {1;} 0,1;
The following, however, all work:
sort {1;} 0,1;
@x = sort {0;} 0,1;
@x = sort {1;} 0;
Chris Thompson
Internet: ce...@phx.cam.ac.uk
JANET: ce...@uk.ac.cam.phx
Edward T Spire
: I don't understand your point - if you don't want to use simple perl
: list operations but instead prefer to work out your own algorithms, then
: presumably when you program in C you don't use the stdio functions in C but
: instead write your own formatted output functions?
: When you program in perl the list operations are part of the language and you
: don't even need to think about what they are or what they do - you just use
: them! I've not used REXX but it sounds like it is a lower-level language
: with a lot fewer features.
The point is this: A language can fall somewhere between two extremes.
1. A "small" language that has a few well selected facilities.
Rexx is the best example of such a language that I know. In fact,
I can hardly think of another language that fits this bill so well.
2. A "large" language that has everything one would ever need.
There are many languages like this: C, PL/1, Perl, etc. It's
much easier to just keep adding features than it is to figure
out a minimum **really useful** set of features.
(1) is easy to learn, and easy for a casual user to retain a high
level of facility (simply because there isn't so much to learn and
rememeber.) And if the facilities available are elegant and well
integrated, the result can be an extremely productive environment.
(2) is not easy to learn, and requires constant use to retain
a high level of facility, simply because there are so many language
features to consider. While the "power programmer" may retain much
of the language in active memory, the casual programmer certainly
cannot. Hence for some class of programmers, the productivity
attainable with a language like Rexx is much higher than that
attainable with a language like C.
So when I am writing in C (or Perl, for that matter) I use the
facilities available. Of course, I often have to look them up
(or refresh my memory by glancing at old code) and this reduces my
productivity. And when I am writing in Rexx, I almost never have
to research the language in the middle of a programming project.
I have seen programming projects where the major human interface
sections have been written in Rexx, and the lower kernel facilities
were written in C. Performance for the most highly repeated
operations, flexibility for those parts of the code that you have
to prototype and evolve to fit the end user's needs. In general,
you need a ratio of one Rexx programmer to three C programmers,
due to the varying level of productivity.
Further, as our world becomes more computer literate, we have two
choices with respect to the casual users (i.e., folks who use computers
but are not programmers by profession)
- They can be completely left out of the programming experience,
so that they cannot customize their world and are "at the mercy"
of the professional programmer.
- They can have a programming language which is designed to fit
their needs, rather than the needs of the professional programmer.
Rexx fills the latter requirement very nicely. This is why Rexx is
the ideal "macro language", allowing an application user to easily
customize an application even though he is not a programmer at heart.
If you choose to teach programming to your child, you can start in
first grade using Rexx, you'll have to wait until sixth grade using C.
And considering that every citizen of a western society will be
a computer user soon, there is certainly a need for this kind of
language.
Larry Wall
It is a "feature" of many Unix's qsort() routines that they do not
check to see if the information returned by the comparison routine is
consistent with itself. With inconsistent comparisons, qsort() tends
to run off the end (or the beginning) of the pointer array it's
rearranging. I guess if you assume consistency, you can write a
slightly faster qsort(). Presumably it was a conscious decision to
optimize for speed over safety, but you never know... :-)
Anyway, there's nothin' much I can do about it, short of writing my own
qsort(), which likely wouldn't be well optimized for the architecture,
and which I don't have time to do anyway. Part of the strength of Perl
is that it relies on the portability and efficiency of the C library,
after all.
Larry
Bruce Elrick
Hmmm...
> perl
print sort {0;} split(//,"Just another Perl mutilator"); print "\n"
ust another JPrerl mutilato
> perl
print sort {1;} split(//,"Just another Perl mutilator"); print "\n"
mu erltortilaP atJusnr eoth
> perl
print sort {-1;} split(//,"Just another Perl mutilator"); print "\n"
Just another Perl mutilator
>
I guess our qsort checks bounds.
As well, from the man page:
The qsort subroutine sorts a table of data in place. It uses the
quicker-sort algorithm.
--
Bruce Elrick Department of Physics
elr...@physics.utoronto.ca University of Toronto
Randal L. Schwartz
Chris> |> Segmentation fault (core dumped)
Chris> The minimal example seems to be
Chris> @x = sort {1;} 0,1;
Chris> The following, however, all work:
Chris> sort {1;} 0,1;
Chris> @x = sort {0;} 0,1;
Chris> @x = sort {1;} 0;
Don't blame Larry for this one... it's the qsort() routine that goes
gaagaa when handed inconsistent values for the ordering.
Unfortunately, adding the proper checking might turn quicksort into
slowsort. :-)
sort of print "Just another Perl hacker,"
--
Randal L. Schwartz / Stonehenge Consulting Services (503)777-0095
mer...@ora.com (semi-permanent) mer...@agora.rain.com (for newsreading only)
phrase: "Welcome to Portland, Oregon ... home of the California Raisins!"
Robert Losee
>Lezz Giles (le...@merlin.dev.cdx.mot.com) wrote:
>The point is this: A language can fall somewhere between two extremes.
>1. A "small" language that has a few well selected facilities.
>Rexx is the best example of such a language that I know. In fact,
>I can hardly think of another language that fits this bill so well.
>2. A "large" language that has everything one would ever need.
>There are many languages like this: C, PL/1, Perl, etc. It's
>much easier to just keep adding features than it is to figure
>out a minimum **really useful** set of features.
[good stuff deleted for space]
>Further, as our world becomes more computer literate, we have two
>choices with respect to the casual users (i.e., folks who use computers
>but are not programmers by profession)
>- They can be completely left out of the programming experience,
>so that they cannot customize their world and are "at the mercy"
>of the professional programmer.
>- They can have a programming language which is designed to fit
>their needs, rather than the needs of the professional programmer.
>Rexx fills the latter requirement very nicely. This is why Rexx is
>the ideal "macro language", allowing an application user to easily
>customize an application even though he is not a programmer at heart.
>If you choose to teach programming to your child, you can start in
>first grade using Rexx, you'll have to wait until sixth grade using C.
I think Ed is right on here. I consider myself to be expert at COBOL
(yes I'll admit to even liking it (for the right applications)); 370
assembler; PL/I; and several 4th generation report writers,
statistical tools, and text processing macros languages. I also
consider myself to be good at Basic, C, and Fortran. And I'm
learning Perl and Smalltalk. But in my twenty years experience REXX
is the most fun and pleasurable language to work with.
It's best thing is it's scaleable. My first REXX programs were just
a set of linear system commands. Then I added conditional
processing, then subroutines, then other things. In languages like C
I immediately had to learn which library's to include to get which
functions to work properly. Ugh, it was quite a learning hump. This
scaleability allows to casual user understanding and access to it's
capabilities. I can imagine showing a non-computer professional how
to adjust their profile/autoexec/login to meet their needs. I'm not
so sure with most other languages, including Perl.
From what I've seen of Perl so far it specializes in terseness. For
high priests & guru's in computerland this can be great--an arcane
language by which to cast spells over the computer. APL in my mind
was the best for that. BUT--they are difficult to learn and keep in
your head. If I had only one language to use it'd be REXX as it's
easy to come back to and an easy "just do it" language.
--
*-------------------------------------------------------------------------*
Robert D. Losee Phone: (402) 472-7663
326 Adminstration Bldg Internet: rlo...@unlinfo.unl.edu
Lincoln NE 68588-0496 Radio Call Sign: N0XLU
Daniel F Boyd
(Edward T Spire) writes:
> 1. A "small" language that has a few well selected facilities.
> Rexx is the best example of such a language that I know. In fact,
> I can hardly think of another language that fits this bill so well.
C belongs in this category. You have control flow, arithmetic,
arrays, structs, and pointers, and that's it. You don't have:
-- string operations
-- automatic conversion of incompatible data types
-- input/output
-- parallel operation, coroutines, monitors, etc.
> 2. A "large" language that has everything one would ever need.
> There are many languages like this: C, PL/1, Perl, etc.
C does NOT belong in this category. None of the things which you seem
to think are features (string operations, I/O) are part of C.
> In general, you need a ratio of one Rexx programmer to three C
> programmers, due to the varying level of productivity.
I think Rexx is about equivalent to the Bourne shell (and not C) in
terms of complexity, portability, and purpose.
I think the reason you find Rexx more productive than C is because you
think
say 'foo'
is more productive than writing
#include <stdio.h>
main() {
fprintf(stdout, "foo\n");
}
I agree. If I wanted to do that I would write
echo foo
Comparisons to C for this task are foolish.
Daniel F. Boyd -- bo...@cs.buffalo.edu
Amy Fisher disclaims all knowledge of this posting.
Chris Sherman
>Lezz Giles (le...@merlin.dev.cdx.mot.com) wrote:
Please note: I'm discussing, not flaming. If it does seem that I let
loose a few flames, I'm sorry. It wasn't intentional.
>The point is this: A language can fall somewhere between two extremes.
>1. A "small" language that has a few well selected facilities.
>Rexx is the best example of such a language that I know. In fact,
>I can hardly think of another language that fits this bill so well.
Fits the bill for what??? Some languages are so good at just a few
things, that they are, in general, useless.
>2. A "large" language that has everything one would ever need.
>There are many languages like this: C, PL/1, Perl, etc. It's
>much easier to just keep adding features than it is to figure
>out a minimum **really useful** set of features.
Two points: C is not a large language. In fact, the syntax of the
language itself offers very little. Libraries makes C really
useful so you need a really good set of libs to make writing
in C useful.
And when has a language with a large set of features every been
considered bad? If I have to keep reimplimenting everything every
time I want to write a program, is that being productive? I think
the only time a large language has ever been considered bad has
been when it was poorly designed in the first place.
>(1) is easy to learn, and easy for a casual user to retain a high
>level of facility (simply because there isn't so much to learn and
>rememeber.) And if the facilities available are elegant and well
>integrated, the result can be an extremely productive environment.
I'm sorry, but if you use something all the time, no matter how complex
it is, then you are going to have an easier time of remembering the
details as time goes on...
For very simple languages, like sh, you can learn everything there is
to know about it in about a day intensive study (I'm not counting
sed, awk, grep, and the other utilities that make sh useful, just sh).
But after that one day, you will never get any better with sh. You have
gone as far as you are ever going to go with it. Consider your favorite
language. Have you learned everything that you are ever going to know
about it? For me and Perl: That's a big NOT!
>(2) is not easy to learn, and requires constant use to retain
>a high level of facility, simply because there are so many language
>features to consider.
There are languages where you have to know a great deal to do the simplist
things. Take C++ for instance. How much to you need to know to create
a object class and use it? Or COBOL? How many lines does it take to do
a moderately simple program?
But simple things can be done simply in perl as well as REXX. But very
complex things (like a batch newsreader that uses sockets, for example)
can be done in Perl. Can they be done in REXX? (Five years ago, when
I knew REXX, the answer was no).
> While the "power programmer" may retain much
>of the language in active memory, the casual programmer certainly
>cannot.
What do you think it takes to be a power programmer?
Well, first of all, I think one would need power tools...
Perl is a power tool. Considering your argument, is REXX?
> Hence for some class of programmers, the productivity
>attainable with a language like Rexx is much higher than that
>attainable with a language like C.
Do you consider power programmers to be productive, or do you think
casual programmers are productive. If you are a manager, and you
want productive programmers, what kinds of tools do you give them?
Do you think you can go wrong giving someone perl? How soon do you
think a power programmer wanna-be will need something greater than perl?
How soon for REXX?
How is that programmers time better spent? Learning perl or REXX?
Final deep question: Is there anything Perl can do that REXX can not.
Is there anything REXX can do that Perl can not.
(or perhaps a better set of questions)
What range of problems can be expressed in perl much easier than can be
expressed in REXX?
What range of problems can be expressed in REXX much easier than can be
expressed in Perl?
>So when I am writing in C (or Perl, for that matter) I use the
>facilities available. Of course, I often have to look them up
>(or refresh my memory by glancing at old code) and this reduces my
>productivity. And when I am writing in Rexx, I almost never have
>to research the language in the middle of a programming project.
Please balance this with how long it actually takes you to express a problem
using both languages.
For instance, suppose it takes you 10 minutes to research a problem for
perl (*) only to find the solution can be done in just a few lines or just
one (hence the infamous term, 'the perl one-liner'), or coming up with a
solution in REXX that takes you 30 minutes to code in very simple
constructs.
(*) by searching personal newsgroup archives, perl book, perl man page,
perl quick reference, asking a co-worker, or asking the net (takes much
longer).
Now which language is more productive, the 10 minute perl, or the 30 minute
REXX. Unfortunately, I don't know anyone who is really good at REXX, so
I can do real time comparisons. I just know that it doesn't take me
any time to code stuff up in Perl, either by using one-liner tricks, or
doing it the hard way using C-like syntax (I have both options in perl, BTW).
>I have seen programming projects where the major human interface
>sections have been written in Rexx, and the lower kernel facilities
>were written in C. Performance for the most highly repeated
>operations, flexibility for those parts of the code that you have
>to prototype and evolve to fit the end user's needs. In general,
>you need a ratio of one Rexx programmer to three C programmers,
>due to the varying level of productivity.
I'm sure perl would do about the same thing here, except that you could
have probably have written a lot of your 'kernal' code in perl because
perl's ability to access many low-level system routines.
>Further, as our world becomes more computer literate, we have two
>choices with respect to the casual users (i.e., folks who use computers
>but are not programmers by profession)
Two issues:
1) Computer literate does not equal programmer. All programmers are
computer literate, but computer literates are not necessarily
programmers.
So what do we do for people who need to program who don't want to be
programmers? Either hire programmers on your staff, contract out the
big jobs to those who could get it done quickly, or let the person
try to learn a script language that meets their needs.
If the person is only going to do the occasional job, then it is probably
a waste of his/her time to learn programming. If they are going to
take the time to learn programming, they might as well learn the more
powerful tools just in case they find they like programming.
>- They can be completely left out of the programming experience,
>so that they cannot customize their world and are "at the mercy"
>of the professional programmer.
>- They can have a programming language which is designed to fit
>their needs, rather than the needs of the professional programmer.
But what happens if these users ever want to become professoinal-class
programmers, but all they know are beginner-class languages?
BTW, has it been proved that perl is hard to use for simple things?
I don't think it is... In fact, for many simple things, it is easier
to use than REXX. (I still remember how hard it was just to open
a file and read the lines into an array in REXX, something I do all
the time in Perl. Of course, I knew REXX really well 5 years ago,
and it has probably changed in many, many major ways since).
>Rexx fills the latter requirement very nicely.
Does that make REXX good or bad for the long run???
>And considering that every citizen of a western society will be
>a computer user soon, there is certainly a need for this kind of
>language.
I agree there should be simple languages for simple uses, but we can
also have complex, yet easy to use languages, for simple and complex
uses, and this will allow anyone to grow in skills to the point where
they can do what they need to do.
My contention is that they can perhaps go further with perl than with REXX.
On a side note, I don't think there is such a thing as a casual programmer.
Just sit the casual user down in front of a GUI like the Mac or Windows,
and they'll never know (or want to know) that a script language even exists.
For the rest of us, we want our power tools that won't give out when the going
gets tough. Perl fits this this requirement very nicely indeed.
(Sorry for the long post.)
--
____/ / / __ / _ _/ ____/
/ / / / / / / Chris Sherman
/ ___ / _/ / /
_____/ __/ __/ __/ _\ _____/ _____/ she...@unx.sas.com
Bernie Cosell
} e...@wrkgrp.COM (Edward T Spire) writes:
}
} >Seriously, I have always found that it was easier for me to whip up
} >what I needed when I needed it than to try and learn and remember how
} >to use all that stuff you have up there.
}
} You haven't been programming for very long, have you.
Hmm, hard to guess what this snide-sounding comment is supposed to mean.
Either *you* haven't programmed very long, or else you've never used a
very complicated language, because Ed is mostly correct there.
Infrequently used language [and application, and operating system]
features are mostly bad things if they provide a simple [but
infrequent] function. There is just too much danger: it is too
easy for things to go awry in a semantically-loaded language, it is
too easy to put in bugs you'll have a VERY hard time finding.
Also, when you are in a position where you use more than one language
or environment with some regularity, things get only worse [one of my
biggest gripes about Unix was not the obscurity of its command line interface,
but that it was *different* from command to command, so instead of having
to learn one [ugly] thing, you had to remember dozens and dozens of exceptions.
Same thing with regular expressions[*]. Making stuff simple and clear is a VERY
worthwhile goal, and adding frills and complexity should be done with
_very_ much introspection.
[*] Over in another newsgroup a guy skewered me bcause I
recommended doing something by a pipeline of grep's, when he
poineted out [correctly] that you could do it with one
'egrep'. What he overlooked was that (1) if you type the
egrep line wrong...just *once* you're way behind [in terms of
total time to get the particular job we were discussing
done], 2) you absolutely couldn't go to a manual [in terms of
efficiency: saving typing 75 characters by thumbing through a
500 page manual nad reading through a 4-page manual-entry is
a LOSER], 3) the egrep RE syntax *varies* from unix to unix,
so you're almost certain to get bagged by (1) or (2). Yes,
he was right, but he just doesn't have the big picture.
/Bernie\
--
Bernie Cosell cos...@world.std.com
Fantasy Farm Fibers, Pearisburg, VA (703) 921-2358
Ronald S. Woan
At the risk of ticking off more of my IBM colleagues, after 6 years of
REXX and five years of PERL, I respectfully disagree. PERL is just as
easy to read and write if the programmer wishes it to be as REXX.
I find the builtin report formatting and string handling (regular
expression stuff especially) so invaluable that I haven't even
bothered to use REXX on my UNIX workstations or OS/2 platforms. If
only there were PERL for the Big Iron and a reliable rexx2perl
converter. :-)
--
+------All Views Expressed Are My Own And Not Necessarily Shared By IBM-----+
+ Ronald S. Woan (IBM VNET)WOAN AT AUSTIN, wo...@exeter.austin.ibm.com +
+ outside of IBM wo...@vnet.ibm.com or wo...@cactus.org +
+ others wo...@soda.berkeley.edu Prodigy: XTCR74A Compuserve: 73530,2537 +
Jack F. Hamilton
>At the risk of ticking off more of my IBM colleagues, after 6 years of
>REXX and five years of PERL, I respectfully disagree. PERL is just as
>easy to read and write if the programmer wishes it to be as REXX.
I almost agree, although the existence of all those $ variables makes Perl
unclear to people who aren't also C or shell programmers (I suppose; I'm
not either of those and so I can't tell; perhaps it's unclear to them as
well).
The problem is that Perl programmers seem to be less likely to wish for
programs which are easy to read and write. Perl programmers, for the most
part, like to write terse programs, preferably taking advantage of various
side effects. REXX, because it's more verbose, makes it more difficult to
accidentally write obscure code.
>I find the builtin report formatting and string handling (regular
>expression stuff especially) so invaluable that I haven't even
>bothered to use REXX on my UNIX workstations or OS/2 platforms.
Absolutely. Perl beats REXX hands down on report writing. I wish they'd
added the output equivalent of the PARSE statement.
>If only there were PERL for the Big Iron and a reliable rexx2perl
>converter. :-)
Has anyone tried to compile Perl under MVS or CMS? What were the results?
You certainly couldn't get all the I/O stuff - the systems aren't similar
enough - but you could get a lot of it, and MVS Perl could be very useful.
F. Scott Ophof
>At the risk of ticking off more of my IBM colleagues, after 6 years of
>REXX and five years of PERL, I respectfully disagree. PERL is just as
>easy to read and write if the programmer wishes it to be as REXX.
The point is, are you a casual user of both REXX and Perl?
If so, then I'd like to hear more about how you manage to retain
the knowledge of both languages.
If not, then I wouldn't dream of disagreeing with your disagreement.
Regards.
$$\
Peter Flass
>
>And when has a language with a large set of features every been
>considered bad? If I have to keep reimplimenting everything every
>time I want to write a program, is that being productive? I think
>the only time a large language has ever been considered bad has
>been when it was poorly designed in the first place.
>
There are two reasons why this is so.
1) "Reserved words" for features most users will never want to use
a'la COBOL which tripped up more programmers who wanted to use
"line-counter" as a variable and never heard of report writer.
2) Heavy overhead in small programs for features which are never used.
PL/I is my favorite for this although it avoids problem #1 and is
otherwise an excellent language.
Rexx avoids #1 entirely, notwithstanding the discussion of "name space
pollution" for external functions. If you _use_ function abc then at
least you have a _chance_ of recognizing a naming conflict when another
abc comes along.
As a scripting language REXX, and interpreted at that, REXX does not
usually have a problem with #2 since ease of use takes precedence over
effeciency, but I have a feeling people are mis-using REXX to write
stuff which might be better written in lower-level languages.
Ťdon't use an electric screwdriver for a chisel or visa-versaŮ.
=====================================================================
= PETER FLASS FLASS@LBDRSCS =
= Systems Programmer tel (518)458-5114 =
= NYS Legislative Bill Drafting Commission =
= 1450 Western Ave. =
= Albany, NY 12203 =
=====================================================================
Michael Cook
> Yes, he was right, but he just doesn't have the big picture.
But you do, and that's your point, right?
(Did someone say "snide"? :-)
M.
Ronald S. Woan
No. I use both languages on a regular basis, though I have to admit
using a third IBM internal language more suitable for incore file/text
processing/formatting and fullscreen application generation than REXX
these days on the mainframe. Not too hard to understand if you have to
be a system programmer on both UNIX and VM/CMS platforms for your
job.
For C programmers, PERL is excessively easy to learn and handle,
especially from UNIX development background.
For non programmers, I'd think that both and BASIC or whatever
applications are using as batch languages on PCs these days are
similarly difficult. Are stem variables any easier to understand than
arrays, or how about I/O with EXECIO. Parse and substringing versus
regular expressions?
F. Scott Ophof
>On Fri, 18 Jun 1993 23:53:12 GMT Chris Sherman said:
>>And when has a language with a large set of features every been
>>considered bad? If I have to keep reimplimenting everything every
>1) "Reserved words" for features most users will never want to use
So you name 2 of the reasons why I like REXX; not much to learn,
easy to learn, and if I need something else, there'll probably be an
external function (package) to do the work without my needing to
re-invent the wheel. I *hate* waste of *any* kind, so programs
that include "even the kitchen sink" are imho B.A.D. That is why I
*do* appreciate the "filter" concept of Unix. (now if the syntax
were easier for ME to understand...)
>effeciency, but I have a feeling people are mis-using REXX to write
>stuff which might be better written in lower-level languages.
>:don't use an electric screwdriver for a chisel or visa-versa:.
But if it CAN be done in REXX, and if the casual user does NOT know
another language, then why not? Of course it's mis-use, but for
them an acceptable solution. I'd rather spend evenings writing
little programs in REXX than tear my hair out trying to remember
the command structures behind single-character commands in other
languages (and KEEP leafing through the manual for every single
command I need to use), simply because I DON'T program day-in-
day-out.
On Mon, 21 Jun 1993 11:01:27 -0400 Peter Flass said:
>Before we add features to REXX let's clean up the incompatibilities that now
>exist, such as I/O facilities (EXECIO etc.).
Well.. something like FILEIN(), FILEOUT() was suggested a while
ago, and only those opsyses which do not have a REXX with TRL's
I/O model still need EXECIO. Even CMS has "seen the light" btw.
The discussions re addition of features have a good side, even if
nothing is added; often enough RAFs crop up, which can be taken
into consideration by Mike and the ANSI committee.
Regards.
$$\
F. Scott Ophof
>In article <930621.03...@mrexx-0.18> "F. Scott Ophof"
><Op...@CS.UWINDSOR.CA> writes:
>>On Sun, 20 Jun 1993 23:43:09 -0400 Ronald S. Woan said:
>>>PERL is just as
>>>easy to read and write if the programmer wishes it to be as REXX.
>>The point is, are you a casual user of both REXX and Perl?
>No. I use both languages on a regular basis, though I have to admit
May I take it as point proven with respect to the CASUAL user?
>For non programmers, I'd think that [C and Perl] and BASIC or whatever
>applications are using as batch languages on PCs these days are
>similarly difficult. Are stem variables any easier to understand than
>arrays, or how about I/O with EXECIO. Parse and substringing versus
>regular expressions?
I personally have more trouble with arrays (numerical-only indices)
than with compound variables. Take the "&" one could substitute
stuff into in EXEC2; *that* gave me a splitting headache.
EXECIO? No problem for me. Wish REXX had stemmed I/O...
Regexps? I can just grasp the concept that square brackets enclose
a range of values. The rest goes over my head. Give me PARSE and
the various SUBSTR() type functions, I'll be OK. :-)
Regards.
$$\
F. Scott Ophof
>If I remember correctly, back in 1987 when I worked at IBM using a CMS 3
>system, there were RXMATHFN, RXSYSFN, RXUSERFN and RXLOCFN modules. Surely
>these weren't local extensions?...
The latter three do sound familiar. RXLOCFN is the name meant for a
LOCal func-pack. Beyond that memory fades... Maybe I just read it
somewhere.
>While we're on higher math, I wrote a module which did Gaussian integration
>of an expression between two numeric limits - but I think that's been lost,
>unfortunately.
System backups don't go back far enough? :-(
Regards.
$$\
Edward T Spire
: In article <1993Jun18.1...@wrkgrp.COM> e...@wrkgrp.COM
: (Edward T Spire) writes:
: > 1. A "small" language that has a few well selected facilities.
: > Rexx is the best example of such a language that I know. In fact,
: > I can hardly think of another language that fits this bill so well.
: C belongs in this category. You have control flow, arithmetic,
: arrays, structs, and pointers, and that's it. You don't have:
: -- string operations
: -- automatic conversion of incompatible data types
: -- input/output
: -- parallel operation, coroutines, monitors, etc.
: > 2. A "large" language that has everything one would ever need.
: > There are many languages like this: C, PL/1, Perl, etc.
: C does NOT belong in this category. None of the things which you seem
: to think are features (string operations, I/O) are part of C.
: > In general, you need a ratio of one Rexx programmer to three C
: > programmers, due to the varying level of productivity.
: I think Rexx is about equivalent to the Bourne shell (and not C) in
: terms of complexity, portability, and purpose.
Make up your mind, Dan. First you say that C is not a "large language"
because most of what you need to know to use it is not really part
of the language definition, but library stuff. Then you say that
C is way more complex than Rexx or bsh.
Maybe the strict ANSI definition of C is kinda small, but in
practice there's a whole bunch more you gotta learn and remember
to write a C program than to write a Rexx program.
...and I am not trying to compare apples and oranges here. I'm just
pointing out that apples and oranges are, in fact, different fruit,
used for different things. My Mom makes great apple pie, and has never
even tried to make an orange pie.
And Rexx and C are as different as apples and oranges.
And perl is a lot more like C than Rexx.
Edward T Spire
: In <1993Jun18.1...@wrkgrp.COM> e...@wrkgrp.COM (Edward T Spire) writes:
: >Lezz Giles (le...@merlin.dev.cdx.mot.com) wrote:
: Please note: I'm discussing, not flaming. If it does seem that I let
: loose a few flames, I'm sorry. It wasn't intentional.
Great! On with the discussion...
: > Hence for some class of programmers, the productivity
: >attainable with a language like Rexx is much higher than that
: >attainable with a language like C.
: Do you consider power programmers to be productive, or do you think
: casual programmers are productive. If you are a manager, and you
: want productive programmers, what kinds of tools do you give them?
Many people need to use computers these days, and not all of them
are professional programmers. They should all be productive, and
different kinds of folks will need different kinds of tools for that
to happen.
: Do you think you can go wrong giving someone perl? How soon do you
: think a power programmer wanna-be will need something greater than perl?
: How soon for REXX?
Yes, I can go wrong giving someone perl. If I give perl to someone
who does not "wanna be" a power programmer, but just wants to write
a little macro to simplify something he does every day with his
spreasdsheet, it will be a big mistake, 'cause he'll have to learn a
whole bunch of stuff he doesn't really need to learn, and will never
remember.
: So what do we do for people who need to program who don't want to be
: programmers? Either hire programmers on your staff, contract out the
: big jobs to those who could get it done quickly, or let the person
: try to learn a script language that meets their needs.
BINGO! Rexx is the script language that meets there needs!
perl is not, too hard to learn, too much to remember, for this
casual user.
: a waste of his/her time to learn programming. If they are going to
: take the time to learn programming, they might as well learn the more
: powerful tools just in case they find they like programming.
That's like saying you should learn to drive an indy race car instead of
an ordinary car, just in case you find you would like to be a race car
driver. Or, you should just hire a chauffer, and forget about learning
to drive yourself around.
: >- They can have a programming language which is designed to fit
: >their needs, rather than the needs of the professional programmer.
: But what happens if these users ever want to become professoinal-class
: programmers, but all they know are beginner-class languages?
Then they have learned the basics of what programming is all about,
without being distracted by the intricacies of a complex language.
Rexx is a great way to teach programming...
: BTW, has it been proved that perl is hard to use for simple things?
Harder to use is not my point. Harder to learn and remember is the
issue.
: >And considering that every citizen of a western society will be
: >a computer user soon, there is certainly a need for this kind of
: >language.
: I agree there should be simple languages for simple uses, but we can
: also have complex, yet easy to use languages, for simple and complex
: uses, and this will allow anyone to grow in skills to the point where
: they can do what they need to do.
Once again, complex and easy to use is probably do-able, especially
if the user uses it all the time and therefore stays in practice.
My claim is that complex and easy to learn, complex and easy to
remember without contant use, is not possible.
: On a side note, I don't think there is such a thing as a casual programmer.
: Just sit the casual user down in front of a GUI like the Mac or Windows,
: and they'll never know (or want to know) that a script language even exists.
Macro programming will be around for as long as people want to
customize their programming world.
Larry Wall
I believe the work is "snipe".
Larry Wall
lw...@netlabs.com
Lezz Giles
|>In article <mcook.7...@fendahl.dev.cdx.mot.com>, Michael Cook writes:
|>
|>} e...@wrkgrp.COM (Edward T Spire) writes:
|>}
|>} >Seriously, I have always found that it was easier for me to whip up
|>} >what I needed when I needed it than to try and learn and remember how
|>} >to use all that stuff you have up there.
|>}
|>} You haven't been programming for very long, have you.
|>
|>Hmm, hard to guess what this snide-sounding comment is supposed to mean.
|>Either *you* haven't programmed very long, or else you've never used a
|>very complicated language, because Ed is mostly correct there.
|>
|>Infrequently used language [and application, and operating system]
|>features are mostly bad things if they provide a simple [but
|>infrequent] function. There is just too much danger: it is too
|>easy for things to go awry in a semantically-loaded language, it is
|>too easy to put in bugs you'll have a VERY hard time finding.
|>
|>Also, when you are in a position where you use more than one language
|>or environment with some regularity, things get only worse [one of my
|>biggest gripes about Unix was not the obscurity of its command line interface,
|>but that it was *different* from command to command, so instead of having
|>to learn one [ugly] thing, you had to remember dozens and dozens of exceptions.
|>Same thing with regular expressions[*]. Making stuff simple and clear is a VERY
|>worthwhile goal, and adding frills and complexity should be done with
|>_very_ much introspection.
But that's the whole point!!!! Larry has given us lists in perl, and he
has given us a set of operations on those lists. The operations are largely
orthogonal (with the exception of splice) and IMHO support the concept of the
ADT of a list up to a reasonable and consistent level. We don't need to
get involved with the implementation details of a list (no CAR or CDR!) but
we have enough power to build more or less any application that we want on
top of the lists.
And if you want a system that has a small number of simple operations then
you probably shouldn't be using Unix! I don't use most of the subroutines
in perl because they are OS-dependent - at a rough count about half the
perl built-in subroutines are there simply to allow access to the underlying
OS. The other half try to provide a compromise between a simple and consistent
programming model and keeping all the good parts of the programming models
of awk, shell and C. IMHO Larry has succeeded in producing a language that
is more consistent, is smaller, is more powerful, and is easier to use than all
of these!
As I said in an earlier post, if you want to recode printf() from scratch
every time you want to print a formatted string in C, then that's fine. Just
don't expect me to agree with you that your code is better or more maintainable
than code written by somebody who has taken the time to learn what functions
are already out there and who uses them.
Lezz
Larry Wall
: wo...@cactus.org wrote:
: I almost agree, although the existence of all those $ variables makes Perl
: unclear to people who aren't also C or shell programmers (I suppose; I'm
: not either of those and so I can't tell; perhaps it's unclear to them as
: well).
This is a bit of a cheap shot, I think. The orthography in which a language
is written has little to do with how easy it is to read that language. To
the extent that there IS an effect, I would argue that it's the writing
systems that LEAVE OUT important information (like vowels) that are harder
to read. We could turn your argument around and claim that in REXX, you
can't tell whether a symbol is a variable or a literal. I would submit
that this tends to make REXX programs unclear.
But the whole It's-All-Greek-To-Me argument is overrated. Let us presume
for the moment that you are a native speaker of English. If you, as a
native English speaker, actually go and study Greek, you'll find that it's
quite easy to learn--the funny alphabet is a problem for maybe a day or
two, and then it isn't a problem, because you think very much like a
Greek speaker thinks. On the other hand, you can go study a
non-Indo-European language that happens to be written with Roman
letters (Basque, say), and it LOOKS easy, but in actual fact it's much
harder to learn, because you simply don't think the way a Basque speaker
thinks.
In computer languages, beauty is only scan deep.
: The problem is that Perl programmers seem to be less likely to wish for
: programs which are easy to read and write. Perl programmers, for the most
: part, like to write terse programs, preferably taking advantage of various
: side effects. REXX, because it's more verbose, makes it more difficult to
: accidentally write obscure code.
This is a valid criticism (in the literary sense). Philosophically,
Perl is much more in favor of Freedom of Expression than is REXX.
This has ramifications all up and down the alley.
Larry
Robert Losee
>Chris Sherman (she...@unx.sas.com) wrote:
[...]
>: a waste of his/her time to learn programming. If they are going to
>: take the time to learn programming, they might as well learn the more
>: powerful tools just in case they find they like programming.
This brought back memories of my good ol' days in the computer
business. Back then I was closer to the operating systems gang. One
of their major traits was sneering at wimps who used COBOL or FORTRAN
instead of 360 assembler language. Their arguement was that to
truely understand and to get the most out of the computer required
assembler. After all, how could anyone really advance in programming
unless they could alter the OS's control blocks (records controling
task's operation in the system) or shift bits left to multiply by
2. It was a hopeless task to convince them that people may not ever
need or care to know what the 7th position of the Program Status Word
did.
Now certainly there's a place for this kind of detailed knowledge, but
the clerk trying to register a student for classes shouldn't spend
any more time learning about this than I should learn about waste
disposal when I throw the trash out.
If a macro and/or script language helps get a job done and is easy to
learn, use, and remember then let the person use it. I know REXX
provides this capability and love it for that reason. If Perl does
the same then great. And if they decide computer programming is for
them then they'll have the basics down about programming and can
approach a more tuneable language like C with greater confidence.
>That's like saying you should learn to drive an indy race car instead of
>an ordinary car, just in case you find you would like to be a race car
>driver. Or, you should just hire a chauffer, and forget about learning
>to drive yourself around.
>: >- They can have a programming language which is designed to fit
>: >their needs, rather than the needs of the professional programmer.
>: But what happens if these users ever want to become professoinal-class
>: programmers, but all they know are beginner-class languages?
They learn another language. Am I unusual these days? I know several
languages very well and several more enough to get around in them.
Are people only learning one language for the rest of their lives?
Eric Giguere
seems to explain a lot.
Me? I use both. What do you expect, I'm Canadian!
BTW, VX-REXX was officially released on Monday at the OS/2 Technical Interchange
in Toronto. Order your copy now!
--
Eric Giguere gig...@csg.UWaterloo.CA
No, my dog's name is not "Rex".
Jeff Savit
>considered bad? If I have to keep reimplimenting everything every
>the only time a large language has ever been considered bad has
>been when it was poorly designed in the first place.
Comments were made about the "Vienna Telephone Directory" that described
the language. Certainly, its size inhibited good implementations and
decreased its acceptance. PL/I was widely subsetted as a result: SP/k
in Toronto (I think) was designed to provide more manageable, smaller
PL/I dialects to work with. You can say that PL/I was "poorly designed
in the first place" (I don't: I rather like PL/I, and like it much more
than C, for instance), but the same criticism was levelled against Algol
68 and Ada. Size has often been cited as a language defect.
>There are languages where you have to know a great deal to do the simplist
>things. Take C++ for instance. How much to you need to know to create
>a object class and use it? Or COBOL? How many lines does it take to do
>a moderately simple program?
COBOL exercises typing skills :-) - but conceptually its quite simple.
One doesn't need to "know a great deal" - just type a lot.
>But simple things can be done simply in perl as well as REXX. But very
>complex things (like a batch newsreader that uses sockets, for example)
>can be done in Perl. Can they be done in REXX? (Five years ago, when
>I knew REXX, the answer was no).
Yes - using RXSOCKET. RXSOCKET is "extra-language", exploiting REXX's
extensible nature, and provides socket interfaces on systems with the
appropriate network facilities. Client/server applications using
sockets or APPC are written in REXX. Other very complicated things are
done in REXX. Many VM/CMS commands are written entirely in REXX. Many
complete application systems are entirely written in REXX.
> Perl is a power tool. Considering your argument, is REXX?
Of course!
>Do you consider power programmers to be productive, or do you think
>casual programmers are productive. If you are a manager, and you
>want productive programmers, what kinds of tools do you give them?
I *am* a manager, as well as a programmer, I give them a tool like REXX
because it is a quite powerful language that nonetheless has a good
syntax, has high functional capabilities, and shields the programmer
from nasty details and from many categories of programmer-created error.
You can knock out code and get results very quickly. That scores as
productivity for me. On VM/CMS, using CMS Pipelines as an additional
power tool, I think it compares very favorably to anything.
>Unfortunately, I don't know anyone who is really good at REXX
Ah, much is explained here. The misconception I *think* you have
(please pardon me if I have this wrong) is that REXX is a pretty weak
language whose shortcomings quickly become restrictive if you are a
"power programmer". Exposure to really good REXX programmers and large
systems written in REXX would probably erase this misconception. REXX
is both powerful and accessible.
It's said that "editors are like religions, except people don't take
their religions as seriously". The same thing is obviously true about
operating systems and languages. A fan of an editor (language,
opsys...) quickly sees the things "wrong" with competitors ("wrong"
because "different from the one he or she loves"). We all do this!
Daniel F Boyd
(Edward T Spire) writes:
> Daniel F Boyd (bo...@acsu.buffalo.edu) wrote:
> : I think Rexx is about equivalent to the Bourne shell (and not C) in
> : terms of complexity, portability, and purpose.
>
> Make up your mind, Dan. First you say that C is not a "large language"
> because most of what you need to know to use it is not really part
> of the language definition, but library stuff. Then you say that
> C is way more complex than Rexx or bsh.
C is more complex than Rexx or sh (and it's called 'sh', not 'bsh' --
nobody but AIX users have something called 'bsh') because C is a
general-purpose compiled programming language. C is a member of the
group that includes Fortran, PL/I, Ada, Pascal, Modula2, and other
such languages. C is less complex than other languages in this class.
Rexx is not a general-purpose compiled language, and neither is the
Bourne shell. Rexx and the UNIX shells (not just sh but also csh,
ksh, and bash) are interpreted, not compiled, and their job is to run
other programs for you.
C is the bricks, /bin/sh is the mortar. Fortran/Cobol are the bricks,
Rexx is the mortar.
Perl is different from both. Perl is Legos.
> Maybe the strict ANSI definition of C is kinda small, but in
> practice there's a whole bunch more you gotta learn and remember
> to write a C program than to write a Rexx program.
This is because in practice there's a whole bunch more you can do with
a C program than you can do with a Rexx program. The Boeing 757 has a
real nice glass cockpit and it's one of the simplest jetliners around.
Your complaint is that the 757 is harder to use than a tricycle.
> And perl is a lot more like C than Rexx.
No, it's not. C is small and elegant. Perl is hairy and large. C is
compiled, Perl is interpreted. You can have extra libraries in C to
do things like window systems and such, but people can and do use C to
write microcode for embedded systems, like missile control hardware
and traffic-light controllers. Perl would be useless for such an
endeavor.
Daniel F. Boyd -- bo...@cs.buffalo.edu
"Amy Fisher went to jail for your sins, at least if your name is Joey."
Joe Ogulin
>COBOL exercises typing skills :-)
That's a mild understatement, Jeff... :-)
>>Do you consider power programmers to be productive, or do you think
>>casual programmers are productive. If you are a manager, and you
>>want productive programmers, what kinds of tools do you give them?
>I *am* a manager, as well as a programmer, I give them a tool like REXX
>because it is a quite powerful language that nonetheless has a good
>syntax, has high functional capabilities, and shields the programmer
>from nasty details and from many categories of programmer-created error.
>You can knock out code and get results very quickly. That scores as
>productivity for me. On VM/CMS, using CMS Pipelines as an additional
>power tool, I think it compares very favorably to anything.
As one of Jeff's programmers, I can tell you that he's very quick to have
one of his staff provide us with MANY useful tools. Some of the things he's
provided, I've used for play and applications development. Other things I've
never touched, either because I have no use for them or don't have the time.
Not only do he and his staff provide the tools, they'll support them too.
While I prefer C for many applications, REXX with CMS Pipelines provides
me with some of the best file handling capabilities around. Now add things
like RXSOCKET, and I'm chugging out programs dealing with data transfers
between platforms and have cut development time because I don't have to
worry about the files themselves. Unfortunately, when I do C for a long
period of time, my REXX goes to the four winds, and vice versa. The syntaxes
are similar, but have enough differences that I'll forget a brace or a "then."
>>Unfortunately, I don't know anyone who is really good at REXX
>Ah, much is explained here. The misconception I *think* you have
>(please pardon me if I have this wrong) is that REXX is a pretty weak
>language whose shortcomings quickly become restrictive if you are a
>"power programmer". Exposure to really good REXX programmers and large
>systems written in REXX would probably erase this misconception. REXX
>is both powerful and accessible.
Back when I worked for Automatic Data Processing, one other programmer and
I developed an entire menu-based system for data entry and processing to
assist the data entry, operations, and sysadmin types with their jobs and
shielding some of the intricacies of VM, set-up of JCL, etc, from them.
All we had was whatever came with CMS release 5. The system we had built
became the corporate standard and when the service machines crashed, nobody
in the office knew how to do the jobs manually... that's how dependent they
became on our "product." :-)
--Joe
Ian Collier
>Rexx is not a general-purpose compiled language, and neither is the
>Bourne shell. Rexx and the UNIX shells (not just sh but also csh,
>ksh, and bash) are interpreted, not compiled, and their job is to run
>other programs for you.
"It's not compiled, so it can't be any good". Not! Just ask anyone who
bought a cheap "home micro" in the mid-80s. There are many excellent
programs written in BASIC for those machines. I have megabytes of them
stacked up on cassettes at home.
If you want to sort a million 80-byte records on disk, then it's probably
not a good idea to write a REXX program to do it. On the other hand, I have
written many perfectly good REXX programs which I wouldn't even have
attempted in sh.
sh is a language for gluing other programs together. This is not so of
REXX; it is a general-purpose computing language. It also happens to be
true that REXX is very good at controlling other applications, and as a
matter of fact it is my opinion that REXX/XEDIT is just about the best
language+editor combination there is (apart, possibly, from REXX/LEXX).
Ian Collier
Ian.C...@prg.ox.ac.uk | i...@ecs.ox.ac.uk
Dave Gomberg
First of all, whether a languages is compiled, semi-compiled, or interpreted
matters NOT A WHIT in deciding the role of the language. All it affects is
the tradeoff between ease of modification and performance.
Second, it doesn't matter whether the complexity is in the language or in
the library(ies). It matters how much complexity shows up in simple
programs. And how much complexity one has to master to do simple things.
And intermediate things. And advanced things. Doing simple things in
FORTRAN is quite simple, but doing advanced things is a nightmare because
of the paucity of native language facilities. Things like associative
memory and recursion make complex things easier. And in a good language,
the relatively complex things you need to know to do complex tasks don't
complicate doing simple tasks.
By these standards, C is extremely complex. REXX is pretty good, except for
the lack of math functions, which makes you have to go to a library reference
to do math instead of finding it in TRL. I am not familiar with PERL, so
I cannot comment on it. But it sounds a bit like APL, which is pretty complex
because it can be quite hard to do simple things in APL because of some
missing primitives.
And any language that can simulate a Turing machine can run anything, so there
is no restriction about what is IMPOSSIBLE in a language, just how hard
(complex) it is to do it. I have written quite large and complex applications
entirely in REXX, and the same app in a mix of REXX and PLI for performance.
REXX is not just a mortar (shell, procedures) language. Those who think it
is might as well run BASIC. Dave
Dave Gomberg, role model for those who don't ask much in their fantasy lives.
GOMBERG@UCSFVM Internet node UCSFVM.UCSF.EDU fax-> (415)731-7797