A recent edit changed case insensitive variables to typeless variables. There were two problems with that:
- The article already listed dynamic data typing (no declarations)
- No replacement text was provided for case independence.
I am reverting the change and then replacing case insensitive variables with case independent tokens, including variable names.
In the same edit I'm including VM and TSO/E as bundled with REXX and I'm mentioning that there are potential surprises for PL/I programmers. Shmuel (Seymour J.) Metz Username:Chatul (talk) 00:36, 12 September 2010 (UTC)
Rexx is not Object Rexx
The infobox shows Rexx as object oriented, which it is not. There is a separate article on Object REXX, where that paradign does apply. Shmuel (Seymour J.) Metz Username:Chatul (talk) 14:33, 31 December 2010 (UTC)
The reference to NOVALUE violates WP:NPOV; quoting feature is totally out of bounds and the disdain for allowing bare words to default to their upper case names is hardly universal. The text should be rewritten in a neutral fashion, although it is certainly appropriate for the text to describe the controversy between the convenience and safety camps. Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:23, 31 December 2010 (UTC)
- Addressed. RossPatterson (talk) 02:01, 11 June 2014 (UTC)
The first line of a Rexx script does not identify the operating system; it identifies the compiler or interpreter. There are several different uses of a special first line.
- The presence of a comment normally identifies the script as Rexx
- In TSO, a Rexx script loaded from SYSPROC must start with
/* REXX */to distinguish it from a clist
- In Unix the first line may be a shebang to identify the language processor
- In OS/2 the first line may be EXTPROC to identify the language processor; normally that is not necessary as an initial comment will let the script run with the default Rexx.
I think that many IBM people would say that REXX's design was highly developed by a community of IBM personnel and customers I think. This was before the internet was in use but PROFS provided email capability at the time. The fact that it was a community-designed language is noteworthy but I cannot find a reference. I hope an IBM person can. Sam Tomato (talk) 17:40, 9 June 2014 (UTC)
- I don't know of any community development of Rexx per se, but here was massive community development of function packages and Rexx-aware commands to support applications written in Rexx, to say nothing of such development tools as VX-REXX and VisPro REXX. Shmuel (Seymour J.) Metz Username:Chatul (talk) 18:12, 10 June 2014 (UTC)
I would assume Sam Tomato is referring to the process Mike Cowlishaw used for having the REXX user community inside IBM vett new features and substantive changes. He has spoken of this many times, and remarked on how valuable it was for developing the language. See, for example, p. 334 in Mike's 1984 IBM Systems Journal article The design of the REXX language:
The most important factor in the development of REXX began to take effect when the first interpreter was distributed over the IBM communication network known as VNET. (This network links over 1400 mainframe computers in forty countries.) From the beginning, many hundreds of people were using the language. All these users, from temporary staff to professional programmers, were able to provide immediate feedback to the designer on their preferences, needs, and suggestions for change. An informal language committee then appeared spontaneously and communicated among themselves and with the designer entirely electronically. The discussions of the committee grew to be hundreds of thousands of lines, and these and the similar quantity of mail from the users were all kept for later review.
As time passed, it became clear that changes in the language were necessary. Using the network, the designer could interactively explain and discuss the changes that were required, some of which were incompatible with the then-current version of the language. The decision to make an incompatible change was never taken lightly, but-because changes could be made relatively easily and explained to users in detail-the language was able to evolve much further than would have been the case if upward compatibility only were considered. Several other important concepts guided the process of enhancing the language.
- It's a wiki, just add the info where it fits to the article, I think I could add a TRL reference, or just use the link shown above, or a link to this document archived on Mike's web site. VX-REXX was 15 (?) years later, that's something different. –Be..anyone (talk) 14:32, 13 January 2015 (UTC)
To me 'able to fully recover following a fatal error' is contradictory: if a full recovery is possible then the error was not fatal. — Preceding unsigned comment added by 18.104.22.168 (talk) 21:30, 4 November 2014 (UTC)
- It seems clear in context that here fatal means that it would terminated execution if not intercepted. If you believe that it is clearer, you could change it to following an otherwise fatal error, but I believe that it is clear as is. Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:47, 6 November 2014 (UTC)
Missing key concepts
It is difficult to appreciate the flavor of Rexx as a scripting language without an understanding of the Rexx variable pool and the environment, especially the definition of function packages related to a particular environment. Shmuel (Seymour J.) Metz Username:Chatul (talk) 17:41, 23 February 2015 (UTC)
- Not related to the Unix environment
- References and notes on talk pages are gross.
- REXX is dead, only very old folks like you and me recall what it was and still use it, everybody else uses Python or Lua.
- IIRC SHVENV is no official part of the language, maybe the stack would come first as missing concept.
- But when you add this, that, or both it's of course your decision, one of the few nice features on a wiki.
- –Be..anyone (talk) 05:12, 24 February 2015 (UTC)
- (Restored my comment as it was, adding tags below what your replies were about: Feel free to remove that, but keep my list together, please. –Be..anyone (talk) 06:37, 25 February 2015 (UTC))
- ad 1
- ad 2
- ad 3
- From ANSI® X3J18-199X American National Standard for Information Systems – Programming Language REXX
5.13 Variable pool
The variable pool interface consists of functions which the configuration shall provide to manipulate the variables and to obtain some characteristics of a REXX program.
These functions can be called from programs not written in REXX — commands and external routines invoked from a REXX program, or traps invoked from the language processor.