On 30.06.2022 01:28, David Crayford wrote:
On 30/06/2022 5:33 am, Paul Gilmartin wrote:
On Wed, 29 Jun 2022 22:22:39 +0200, Bernd Oppolzer wrote:
This is an old OS/2 REXX program (from the 1990s, IIRC),
used to traverse a directory tree recursively and issue a command in
every subdirectory found:
<snip!>
... with local variables protected by "procedure".
Protected? That's a good one! Another reason to hate on REXX is the lack of lexical scoping. It's
ok for small programs but as soon as you start to scale
it's a nightmare when you"i" loop counter gets clobbered in a subroutine. "procedure" helps but
then you have to use "expose" which normally results in
using a compound global variable such as g._namespace. REXX is a language that
you program into.
In classic REXX there is no means to fetch stems by reference, therefore the need to be able to
EXPOSE stems in internal routines which create a local scope using the PROCEDURE keyword.
ooRexx alleviates this need as it allows for fetching stems in internal routines/procedures using
e.g. "USE ARG mystem." instead of "PARSE ARG" which only works on string values and therefore cannot
fetch a stem by reference.
Having ooRexx available you immediately gain additional scopes and great new abilities. One being
that one can define routines having their own scope (and the ability to make them directly available
to other Rexx programs just by adding the PUBLIC option to the routine directive's name).
Another cool feature that can help simplify certain kinds of problems is the notion of "runtime
environments" in ooRexx:
* ooRexx package environment: in ooRexx a "package" is a file that contains
Rexx code with
routines that may or may not be public, classes (types, structures) that may
or may not be
public, method routines that may or may not be assigned to classes and much
more. In addition a
programmer can use the package local environment to store values that can be
retrieved from
anywhere within that package.
* ooRexx local environment: ooRexx' implementation can be characterized to be
incredibly powerful.
Among other things one can create arbitrary many *different* ooRexx
interpreters within the same
process if need be. Each such ooRexx interpreter instance has its own copy
of the ooRexx local
environment which provides the instance's stdin, stdout, stderr,
traceoutput, debuginput, stdque
streams/monitors. This way each ooRexx interpreter instance will have
separated such
streams/monitors.
* ooRexx global environment: this environment contains all entries that are
meant to be globally
available to each Rexx program in each ooRexx interpreter instance like the
ooRexx supplied classes.
All these environment are ooRexx directories and used by the ooRexx interpreter at runtime to locate
entries for environment symbols. An "environment symbol" is a Rexx symbol that starts with a dot
like ".directory". The ooRexx interpreter will remove the dot and lookup the above environment
directories in the given order to locate an entry "DIRECTORY" and will return it, once found. (If no
entry could be found in these environments then the lookup will result in the environment symbol
itself, i.e. the uppercased string value of the environment symbol, e.g. '.no.entry' would yield
'.NO.ENTRY').
The dynamic nature of REXX has been carried over to ooRexx and enhanced considerably. However one
would just exploit that power if need be.
---rony
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
