NetRexx -- easier Java programming


This is the conclusion of a 3-part article by Michael F. Cowlishaw, the creator of the REXX language.  This article was first published in the "Java Report", June 1997 (pp 45-48).

See Sep and Oct '98 of the 1998 RexxLA newsletter for parts 1 and 2.

Decimal Arithmetic

As already mentioned, the decimal arithmetic in NetRexx is implemented by the Rexx class, which can, of course, be used by Java programs independently of NetRexx.  This will be useful to many Java programmers, and is worth a little more description.  (A full description of the arithmetic may be found in reference books on Rexx or NetRexx, or in the ANSI Standard for Rexx [X3.274-1996].)

The arithmetic was designed as a full-function decimal floating point arithmetic, based on the principles that people are taught at school (for example, trailing zeros are preserved in most operations: 1.20*2 gives 2.40, not 2.4).  Being a decimal arithmetic, exact results will be given when expected (for instance, 0.1 has an exact representation).

As there's just one type of number, there are no discontinuities such as integer overflows at 32 bits.  By definition, exponents in the range E-999999999 through E+999999999 are allowed, with a default mantissa precision of 9 decimal digits.  The precision is selectable by the programmer, so you can calculate to thousands of digits if necessary. The language imposes no upper limit on precision, though in practice, memory or processor constraints may limit some calculations.

The arithmetic methods supported by the Rexx class are defined by the interface class RexxOperators.  In principle, NetRexx could be trivially extended to permit overloading of the arithmetic operators for any class that implements this interface -- though at present it is not clear that this would be an improvement.

Scripting

Java and NetRexx are good languages for application development. There's another very important use for computer languages, however:  scripting.  This is a loosely-defined and loosely-used term, so it needs qualification: generally, a scripting language is a language that, like Rexx, is suitable for small-scale programming (such as customization, the 'glueing' together of components, macro writing, and the like), and is strong in string-processing, with unobtrusive typing.  In addition, scripts are expected to be, in effect, executed from source at the time of execution (which will usually be at a time or place remote from the time of writing).

The need for execution from source puts a severe constraint on the syntax of a language.  Unless the language is expected to be stagnant, and have only a very short lifetime, it must be possible to extend and enhance the language over time as the needs and expectations of its users change.  (While this is a desirable feature of all languages, it is not a necessary feature for those which are executed only from a derivative binary representation, because changes to the language syntax do not invalidate the existing binary representations.  Scripting languages, in contrast, must be extendible without invalidating existing source.)

Many details of syntax can make a language hard to extend without breakage.  The most significant, and most common, problem is reserved keywords.  If a language depends on reserved keywords to disambiguate its syntax, then any addition to that set of keywords is likely to cause correct programs written earlier to fail -- for example, if that keyword had been used as a variable or method name.

Rexx was designed as a scripting language and care was taken to make it robust and extendible -- but even Rexx reserved keywords within statements (for example, in the 'do' instruction), which made certain requested extensions impossible.  Learning from this experience, NetRexx uses a stronger rule: once a name has been used for a variable, it cannot be a keyword in the same context.  This means that it has no reserved keywords, and can easily be extended in the future.  It is therefore safe for both application development and for scripting -- perhaps the first language that makes the distinction between these roles obsolete.

The NetRexx reference implementation

The initial, reference, implementation of NetRexx  is available free of charge.  It is a compiler that first translates the NetRexx source code into Java source code; a Java compiler is then used to generate the Java bytecodes (class files) for execution.  NetRexx classes and Java classes are entirely equivalent: NetRexx can use any Java class (and vice versa).

NetRexx is already being used for a wide variety of applications; in addition to World Wide Web applets, it has been used for writing databases, performance analysers, input and output classes, document viewers, debuggers, and development environments.

The reference compiler (NetRexxC), too, is written in NetRexx, and should run on any Java platform that supports the Java toolkit and compiler (javac).  By default, NetRexxC automatically calls the javac compiler to create class files, but you can use other Java compilers if you wish (the generated Java source is accessible).

NetRexxC implements the NetRexx 1.00 language as defined in the book "The NetRexx Language" (ISBN 0-13-806332-X), published by Prentice Hall (January 1997).

Questions?

It's hard to cover the subtleties of a new language in a brief article. If it has piqued your curiosity a little -- and I hope it has -- then you can find a lot more about it at the NetRexx web site:

http://www2.hursley.ibm.com/netrexx

There you'll find introductory material, samples and examples, formal reference documents, links to the NetRexx FAQ file and other interesting items, and the NetRexx packages to download.

Mike Cowlishaw
IBM Fellow
mfc@uk.ibm.com