I believe that REXX only directly supports one of those two mechanisms,
namely the symbol table lookup and not true indexed arrays. Although
one may use in a REXX program "symbol.ix", where ix in that particular
program is always a positive numeric integer, I would think this only
gives the illusion of an indexed array and not the reality, since an
interpreter like REXX cannot assume that later stem arguments will
continue to be numeric, and also "symbol.1" is distinct from "symbol.001".
The distinction that John draws is not really related to the number of
dimensions involved or to the concept that a multi-variate function may
be re-conceptualized as a single-variate function whose domain is a set
involving a product of the original domains. The distinction made is
rather one of whether the original variable domains consist of
consecutive integer values or not. If so, the process of locating and
retrieving values can be done much more cheaply by offset calculation.
Indexed lookup is definitely more efficient, and simpler techniques can
be used to implement it -- and this may affect the contexts in which
each approach is best used or even practical. But, functionally,
indexed arrays are just a special subset of symbol table lookup: where
the symbol values (consecutive integers) are so predictable they need
not be stored, the hashing function to locate an entry is the simple
offset calculation previously indicated, and collisions with conflicting
symbols are known to be impossible.
Joel C Ewing
On 11/06/2010 02:06 PM, john gilmore wrote:
Joel Ewing wrote:
| This technique in effect maps any number of dimensions to a single dimension.
and there is an important functional sense in which his statement is correct;
but 1)
it confounds two very different mechanisms, 2) it is not a scheme
specific to REXX,
and 3) these two mechanisms have their own distinct, non-overlapping uses.
Let us look first at subscripting, specifically at a one-dimensional,
eight-element single-byte
array having what I shall call the identifier x,
|0|1|2|3|4|5|6|7|
Suppose now that we wish to access element i, 0<= i<= 7 of x. If the address
of
this array is addr(x) then the address of its i-th element is just>
addr(x) + i.
If now we consider another, two-dimensional, 2 x 4, eight-element single-byte
array having the identifier y,>
|0,0|0,1|0,2|0,3|1,0|1,1|1,2|1,3|>
the address of its element having the subscripts i, j is just
addr(y) + j + (i - 1)4
Here eight bytes of storage can be viewed as a one-dimensional array, as a
two-dimensional one,
or, on occasion, as both. The location of an element of a one-, two-,
or n-dimensional array
is determined arithmetically. (For simplicity I have made these
elements single-byte ones
that are stored in zero-origin, row-major sequence. Some arrays are
one-origin ones; most
have elements more than a single byte in length, and some FORTRAN
dialects still store arrays
in column-major order; but these differences are trivial.) What is
important is that
subscripting uses numeric function. Its argumet is a set of one or more
subscripts and
its value is an address. All subscripting schemes are devices for
viewing a one-dimensional
sequence of storage locations as a multidimensional one.
Historically, identifiers or variable names were specified at program-writing
time,
but they can also be created at program-execution time. One needs a
table of
identifiers--It is/was often called a symbol table--and a convention for
specifying/identifying
the value of an identifier.
In the IBM HLASM macro language, for example, ordinary set symbols have names
like
counter,&switch, or&abort that are given to them at program-writing
time. They can
also be created later, and these created set symbols are distinguished
from ordinary
set symbols using an extra set of parentheses. Thus
|&name0 setc 'gubbins' --set-symbol identifier
| gblc&(&name0) --created set symbol
Encoumntering these statements, the HLASM macro processor loks in its symbol
table
for the identifier 'gubbins'. If it finds that identifier, its value is
used.
If not a created global set symbol is added to the appropriate symbol table.
We can do much more interesting things too. Consider
|&name1 setc 'name0'.'&sex'.'&age'|
gblc&(&name1)
where&sex is always either 'M' or 'F' and&age is always one of '000', '001',
'002', . . . , '999'.
If then on some occasion&name1 has the value 'gubbinsM024' we ca view the
statement
|&name1 seta&(&name1)+1
as incrementing the count of 24-year-old males in some population. In
practical terms
this is much is scheme is very similar to one that uses a 2 x 1000
array, but the mechanism
used to implement it is very different: ituses not subscripting but a
large number of
scalar identifiers that have an internal, decodable structure like that
of a part number,
insdurance-policy number or savings-account number, here some or all of
gubbinsF000, gubbinsF001, . . . , gubbinsF999, gubbinsM000, gubbinsM001, . .
. , gubbinsM999.
Identifier-construction schemes like these are slower, much slower, than
arithmetic subscripting;
but if a table is sparsely populated, i.e., if only a few of the
identifiers that a particular sceme
makes possible are in fact used, they can be very useful.
They have another important use in both the HLASM and REXX. They can be used
to make data
'reentrant' in a Pickwickian but important sense. In certain HLASM
table-generation macros,
for example, I accumulate information in sets of global set symbol of
the form
|&valueid setc '&macname'.'&tabname'.'<whatever>'
| gblc&(&valueid)(1)
and the use of this scheme permits two, three, or n different tables of the
same sort
but having different tabname= values to be assembled concurrently: the
data for table alpha
are distinguishable and distinguished from the data for table delta
because 'alpha' and
'delta' appear as positional substrings in the different,
non-overlapping identifiers of
their data. Table-generation macros that use this scheme are
reentrant in much the same
sense in which procedures trhat use different blocks of automatic
storage are reentrant.
John Gilmore Ashland, MA 01721-1817 USA
...
--
Joel C. Ewing, Fort Smith, AR jcew...@acm.org
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
