Current restrictions
The NetRexx processor is rapidly evolving; features are being added
almost daily to complete the implementation of the language. As of this
version there are still a number of restrictions, listed below.
Please note that the presence of an item in this section is not a
commitment to include that item or remove a restriction in some future
update; NetRexx enhancements are dependent on on-going research, your
feedback, and available resources. You should treat this list as a
'wish-list' (and please send in your wishes).
Implementation in progress
These items are work-in-progress:
-
The current NetRexx documentation assumes knowledge of Rexx. Work
on a free-standing language specification is well underway.
-
Only the following 'standard Rexx' methods are fully implemented, so
far. For details on how to use these, please see Object Rexx
documentation (or deduce from Rexx or ANSI Rexx documentation):
abbrev abs center centre changestr countstr copies datatype
lastpos left length pos reverse right sign space strip substr
subword verify word wordindex wordlength words
The following new methods have been added:
lower upper
Additional methods from the standard Rexx set will be added over
time.
Not yet implemented
The following planned language elements are not yet available (in
a potential 'to-do' order):
-
Some features of TRACE
-
Case-insensitive method and property lookup (along with OPTIONS
STRICTCASE, for those who prefer exact matching).
-
Power operator (on both primitive and Rexx operands).
Short-term restrictions
The following restrictions apply to the current NetRexx processor; they
will be removed in due course:
-
Only one error is reported in a given translation.
-
Errors are shown as cryptic formal identifiers rather than
descriptive text. This is pending alignment with the ANSI Rexx
Standard's error messages.
-
Identifiers (names of variables, etc.) cannot include accented
characters.
-
NetRexxC does not check for uninitialized variables. JAVAC will
report these, but it would be preferable for NetRexxC to report them
in context. Note that line numbers reported by JAVAC should match
the line numbers in your NetRexx program.
-
NetRexxC does not check for constant (static) references to
properties or methods that are not constant (and vice versa). JAVAC
will report these. Note that line numbers reported by JAVAC should
match the line numbers in your NetRexx program.
Missing information and javac restrictions
At present, the Java class APIs do not expose full information on
classes and their contents (if necessary, NetRexxC could read and parse
the binary .class files for this information; this is under
investigation). This leads to the following restrictions:
-
NetRexxC cannot detect the modifiers for a class (such as FINAL or
ABSTRACT) hence cannot warn of an attempt to subclass a FINAL class.
JAVAC will report this. Note that line numbers reported by JAVAC
should match the line numbers in your NetRexx program.
-
NetRexxC does not check for certain unsignaled exceptions (that are
caught), and exceptions signaled but not caught. JAVAC considers
some exceptions 'special' and will report these. Note that line
numbers reported by JAVAC should match the line numbers in your
NetRexx program.
NetRexxC by default uses the javac compiler to generate bytecodes (class
file). The following problem may occur in larger methods:
-
NetRexxC does not restrict the number of local variables used or
generated. However, the JAVAC compiler currently fails with
unrelated error messages (such as 'statement unreachable' or
'variable may be uninitialized') if asked to handle more than 63
local variables.
Long term restrictions
The following restrictions are due to the use of a translator, and would
probably only be lifted if a direct-to-bytecodes NetRexx compiler were
built.
-
'$' cannot be used in the names of variables. (This restriction
could perhaps be lifted for the names of properties, methods, and
classes, if useful.)
-
Externally-visible names (property, method, and class names) cannot
be Java reserved words (you probably want to avoid these anyway).
JAVAC will report these.
-
Some binary floating point underflows may be treated as zero instead
of being trapped as errors.
-
Side-effects of calls to this() and super() in constructors may be
seen before the method and method call instructions are traced --
this is because Java does not permit tracing instructions to be
added before the call to this() or super().
-
The results of expressions consisting of the single term 'null' are
not traced.
[ previous section | contents]
From 'nrinst.doc', version 0.75.
Copyright(c) IBM Corporation, 1996. All rights reserved. ©