For example, let’s assume a BASIC interpreter does not have the logical AND operator. To be consistent with similar, existing operators one would like to use "AND" in the following syntax:
- A AND B
(A,B are any valid operands). Furthermore, one would want this new operator to have a priority higher than "OR" and lower than "NOT" so that
- NOT A AND B OR C
would mean
- (NOT A) AND (B OR C)
The only way to do this is to modify one's BASIC interpreter. Although not impossible, this is usually very difficult because of the following reasons:
(1) Most BASIC's are distributed without the interpreter source code (or not in machine-readable form). (2) One would have to learn this program and design a change. One modification might be "patched in", but many probably could not. Such a modified interpreter might not be compatible with future releases from the manufacturer. Errors might be introduced into other parts of the interpreter by this modification. (3) The process of changing is time consuming. Before one could try the new version, one would have to assemble, link, load, and possibly write a PROM. (How long would this take on your system?)
Another alternative would be to use a BASIC FUNCTION to add the AND operator, but it would have to be referenced as:
- AND (A,B)
If NOT and OR were also FUNCTIONS, (NOT A) AND (B OR C) would have to be written as:
- AND (NOT(A), OR(B,C))
This later form is lower level, less readable, and inconsistent with the intrinsic operators.
The addition of an AND operator in FORTH is as simple as any other programming addition; it would require one line of source code. The FORTH assembler could be used to take advantage of a particular processor’s instruction, or the compiler could be used, resulting in machine transportability! Other differences from the example of modifying BASIC are: (1) Nothing existing in the FORTH system needs to be changed, so no learning is required, no errors are introduced to the existing system, and compatibility with future releases is preserved. The source of the FORTH kernel is not even necessary. (2) The new operator can be tried immediately after it is defined; if it is wrong it can be fixed before any further use is made of it. (3) This new operator its used exactly the same as any FORTH operator. So it may be mixed with existing operators in a totally consistant manner.
APL fans will point out that all the above is true for APL also. For something as simple as "AND" there is little difference. However, APL allows only monadic (single operand) and diadic (two operand) operators; FORTH operators can be written to accept as many operands as the programmer desires.
The previous discussion addressed the extension of the FORTH language, but it is almost as easy to extend the FORTH compiler! New compiler control structures (e.g., the CASE construct) can be added without changing any of the existing compiler. Or the existing compiier can be modified to do something different. To maintain compatibility with the existing compiler, the modifications could be part of a user~defined "vocabulary" so that both versions would be selectively available. Furthermore, one can write an entirely new compiler which accepts either the FORTH language or another language. (Complete BASIC interpreters have been written in FORTH.)
The choice of a computer language for a given application (including system development) should optimize the following attributes: (1) Be terse (i.e., the highest level for the application) (2) Be unambiguous (3) Be extensible (e.g, language, data types, compiler) (4) Be efficient (5) Be understandable (e.g., self documentation) (6) Be correct (e.g.,testing, proving assertions, consistency checks) (7) Be structured (e.g., structured programming, reentrant, recursive) (8) Be maintainable (e.g., modular, no side effects)
FORTH is a compromise among these goals, but comes closer than most existing programming languages.
- ;S KIM HARRIS
REFERENCES
1 Halstead, Maurice, Language Level: A Missing Concept in Information Theory, Performance Evaluation Review, ACM SIGMETRICS, Vol. 2 March '73.
2 McKeeman, Horning, and Wortman, A Compiler Generator, Prentice-Hall, 1970.
3 Brown, James Cooke, Loglan 1: A Logical Language, Loglan Institude, 2261 Soladad Rancho Road, San Diego, CA (714) 270-9773
