Defining programs
Within the basic skeleton the programmer must provide for the individual operators and predicates, generally through a symbol table indexed by ASCII characters. REC is not required to work with single character symbols, but the complexity of parsing a program in the compiler is increased by a whole order of magnitude if anything but the simplest variants on this restriction are allowed.
Over the years extensions to REC have occurred, and specialized applications have developed. The most important extension provides for creating new subroutines. They are designated by a composite symbol such as @s; ``at sign'' joins the list of reserved letters. Subroutines are defined by enclosing a list of definitions (followed by a main program) within braces:
(...) s (... ...);
in fact such a braced list may be included anywhere in a REC expression that operators, predicates, or subexpressions can occur. The scope of the definitions lies exclusively within the braces; the same symbols can be reused elsewhere or even recursively.
Certain additional features have proved convenient, but are common to most programming languages. One is to ignore space, tabs, and so on unless they are an actual part of quoted data; the other is to permit comments. In REC , comments are enclosed recursively within square brackets, which permits disabling debugging or trial segments without removing them completely.
It is hard to work with programs which are incapable of providing data to themselves; some form of quotation usually has to be provided. In some contexts, recognizing numbers as such and transforming them into a binary representation is essential; in others quoted character strings suffice.
A counter, written !n!, is a useful predicate, true n times and then false; (!12!x:;) would perform the operation x a dozen times.
The two most important levels of specialization that we have worked with include, first, introducing a pushdown list and, second, introducing a workspace.
The whole mechanism of numerical processing goes well with the first; one predefines arithmetic operations, comparisons, input and output conversion, and so on, as appropriate operators and predicates. Fixed subroutines attend to such things as square roots or trigonometric functions, just as is done in other programming languages. When specific calculations are required, they are performed by writing programs.
Dealing with arbitrary arrays requires further machinery; consequently an arithmetic REC has a closer affinity to APL than to FORTRAN . Nevertheless fixed arrays are convenient, from which a matrix version of REC can be devised.
The second extension really produces an exotic structure, suitable for editors, compilers, and the like. However, both of these versions of REC are much more ambitious than what is included in LCAU .
Harold V. McIntosh
E-mail:mcintosh@servidor.unam.mx