The NetRexx Language

Cours The NetRexx Language, tutoriel & guide de travaux pratiques en pdf.

The case of names and symbols

In general, NetRexx is a case–insensitivelanguage. That is, the names of keywords, variables, and so on, will be recognized independently of the case used for each letter in a name; the name “Swildon” would match the name “swilDon”.
NetRexx, however, uses names that may be visible outside the NetRexx pro-gram, and these may well be referenced by case-sensitive languages. There-fore, any name that has an external use (such as the name of a property, method, constructor, or class) has a defined spelling, in which each letter of the name has the case used for that letter when the name was first defined or used.
Similarly, the lookup of external names is both case-preserving and case-in-sensitive. If a class, method, or property is referenced by the name “Foo”, for example, an exact-case match will first be tried at each point that a search is made. If this succeeds, the search for a matching name is complete. If it is does not succeed, a case-insensitive search in the same context is carried out, and if one item is found, then the search is complete. If more than one item matches then the reference is ambiguous, and an error is reported.
Implementations are encouraged to offer an option that requires that all name matches are exact (case-sensitive), for programmers or house-styles that prefer that approach to name matching.
Copyright (c) IBM Corporation 1997. All rightsSpecificationreserved1.00.
Programs written in the NetRexx language manipulate values, such as names, numbers, and other representations of data. All such values have an associated type(also known as a signature).
The type of a value is a descriptor which identifies the nature of the value and the operations that may be carried out on that value.
A type is normally defined by a class, which is a named collection of values (called properties)and procedures (called methods) for carrying out operations on the properties.
For example, a character string in NetRexx is usually of type Rexx, which will be implemented by the class called Rexx. The class Rexx defines the properties of the string (a sequence of characters) and the methods that work on strings. This type of string may be the subject of arithmetic operations as well as more conventional string operations such as concatenation, and so the methods implement string arithmetic as well as other string operations.
The names of types can further be qualified by the name of a packagewhere
the class is held. See the package instruction for details of packages; in summary, a package name is a sequence of one or more non-num eric symbols, separated by periods. Thus, if the Rexx class was part of the netrexx.lang package,9 then its qualified typewould be netrexx.lang.Rexx.
In general, only the class name need be specified to refer to a type. However, if a class of the same name exists in more than one known (imported) pack-age, then the name should be qualified by the package name. That is, if the use of just the class name does not uniquely identify the class then the ref-erence is ambiguous and an error is reported.

Primitive types

Implementations may optionally provide primitive typesfor efficiency. Primi-tive types are “built-in” types that are not necessarily implemented as classes. They typically represent concepts native to the underlying environment (such as 32-bit binary integer numbers) and may exhibit semantics that are differ-ent from other types. NetRexx, however, makes no syntax distinction in the names of primitive types, and assumes binary constructors(see page 116) exist for primitive values.
Primitive types are necessary when performance is an overriding consider-ation, and so this definition will assume that primitive types corresponding to the common binary number formats are available and will describe how they differ from other types, where appropriate.
9 This is in fact where it may be found in the reference implementation.
Specification 1.00 Copyright (c) IBM Corporation 1997. All rights reserved.
In the reference implementation, the names of the primitive types are:
boolean char byte short int long float double where the first two describe a single-bit value and Unicode character respec-tively, and the remainder describe signed numbers of various formats. The main difference between these and other types is that the primitive types are not a subclass of Object, so they cannot be assigned to a variable of type Object or passed to methods “by reference”. To use them in this way, an object must be created to “wrap” them; Java provides classes for this (for example, the class Long).

Dimensioned types

Another feature that is provided for efficiency is the concept of dimensioned types,which are types (normal or primitive) that have an associated dimen-sion (in the sense of the dimensions of an array). Dimensioned values are described in detail in the section on Arrays (see page 43).
The dimension of a dimensioned type is represented in NetRexx programs by square brackets enclosing zero or more commas, where the d imension is given by the number of commas, plus one. A dimensioned type is distinct from the type of the same name but with no dimensions.

Examples:
Rexx
int
Rexx[]
int[,,]
The examples show a normal type, a primitive type, and a dimensioned ver-sion of each (of dimension 1 and 3 respectively). The latter type would result from constructing an array thus:
myarray=int[10,10,10]
That is, the dimension of the type matches the count of indexes defined for the array.

TERMS
A term in NetRexx is a syntactic unit which describes some value (such as a literal string, a variable, or the result of some computation) that can be manipulated in a NetRexx program.
Terms may be either simple (consisting of a single element) or compound (con-sisting of more than one element, with a period and no other characters between each element).

Simple terms
A simple term may be:
• A literal string(see page 5) – a character string delimited by quotes, which is a constant.
• A symbol (see page 7). A symbol that does not begin with a digit identi-fies a variable, a value, or a type. One that does begin with a digit is a numeric symbol, which is a constant.
• A method call(see page 19), which is of the form
symbol ( expression , expression … )
• An indexed reference(se page 42), which is of the form10
symbol ‘[‘ expression , expression … ‘]’
• A sub–expression(see page 34), which consists of any expression enclosed within a left and a right parenthesis.
Blanks are not permitted between the symbol in a method call and the “(”, or between the symbol in an indexed reference and the “[”.
Within simple terms, method calls with no arguments (that is, with no expressions between the parentheses) may be expressed without the paren-theses provided that they refer to a method in the current class (or to a static method in a class usedby the current class) and do not refer to a constructor (see page 23). An implementation may optionally provide a mechanism that disallows this parenthesis omission.
10 The notations ‘[‘ and ‘]’ indicate square brackets appearing in the NetRexx program.

Compound terms
Compound terms may start with any simple term, and, in addition, may start with a qualified class name (see page 75) or a qualified constructor (see page 19). These last two both start with a package name (a sequence of non-numeric symbols separated by periods and ending in a period).
This first part of a compound term is known as the stubof the term.

Example stubs
« A string »
Arca
12.10
paint(g)
indexedVar[i+1]
(« A » « string »)
java.lang.Math –– qualified class name netrexx.lang.Rexx(1) –– qualified constructor
All stubs are syntactically valid terms (either simple or compound) and may optionally be followed by a continuation,which is one or more additional non-numeric symbols, method calls, or indexed references, separated from each other and from the stub by connectorswhich are periods.
the evaluation proceeds as follows:
1. The stub (« A rabbit ») is evaluated, resulting in a string of type Rexx.
2. Because that string is of type Rexx, the Rexx class is then searched for the word method. This is then invoked on the string, with argument 2. In other words, the word method is invoked with the string “A rabbit” as its current context (the properties of the Rexx class w hen the method is invoked reflect that value).
This returns a new string of type Rexx, “rabbit” (the second word in the original string).
3. In the same way as before, the pos method of the Rexx class is then invoked on the new string, with argument ‘b’.
This returns a new string of type Rexx, “3” (the position of the first “b” in the previous result).
This value, “3”, is the final value of the term.
The remainder of this section gives the details of term evaluation; it is best skipped on first reading.

Simple term evaluation
All simple terms may also be used as stubs, and are evaluated in precisely the same way as stubs, as described below. For example, numeric symbols are evaluated as though they were enclosed in quotes; their value is a string of type Rexx.
In binary classes (see page 48), however, simple terms that are strings or numeric symbols are given an implementation-defined string or primitive type respectively, as described in the section on Binary values and operations (see page 114)

Part 1: NetRexx Language Definition 
Section 1: Notations
Section 2: Characters and Encodings
Section 3: Structure and General Syntax
Section 4: Types and Classes
Section 5: Terms
Section 6: Methods and Constructors
Section 7: Type conversions
Section 8: Expressions and Operators
Section 9: Clauses and Instructions
Section 10: Assignments and Variables
Section 11: Indexed strings and Arrays
Section 12: Keyword Instructions
Section 13: Class instruction
Section 14: Do instruction
Section 15: Exit instruction
Section 16: If instruction
Section 17: Import instruction
Section 18: Iterate instruction
Section 19: Leave instruction
Section 20: Loop instruction
Section 21: Method instruction
Section 22: Nop instruction
Section 23: Numeric instruction
Section 24: Options instruction
Section 25: Package instruction
Section 26: Parse instruction
Section 27: Properties instruction
Section 28: Return instruction
Section 29: Say instruction
Section 30: Select instruction
Section 31: Signal instruction
Section 32: Trace instruction
Section 33: Program structure
Section 34: Special names and methods
Section 35: Parsing templates
Section 36: Numbers and Arithmetic
Section 37: Binary values and operations
Section 38: Exceptions
Section 39: Methods for NetRexx strings
Appendix A: NetRexx Syntax Diagrams