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 'classic Rexx' methods are fully implemented,
so far. For details on how to use these, please see the NetRexx
language definition, at: http://www2.hursley.ibm.com/nrl/
abbrev abs b2x center centre changestr countstr copies c2d c2x
datatype d2c lastpos left length max min pos reverse right sign
space strip substr subword verify word wordindex wordlength words
x2b x2c
The following new methods have been added:
lower upper
Not yet implemented
The following planned language elements are not yet available (in
a potential 'to-do' order):
Short-term restrictions
The following restrictions apply to the current NetRexx processor; it is
intended that they will be removed in due course:
-
Only one error is reported in a given translation (warnings,
however, do not stop compilation).
-
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.
-
The EXTENDS, IMPLEMENTS, and USES phrases of the CLASS instruction
cannot refer to a class defined later in the same program.
-
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 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.81.
Copyright(c) IBM Corporation, 1996. All rights reserved. ©