GERMAN REVISITED
In the last issue of FORTH DIMENSIONS we showed how to create a bi-lingual (or multi-lingual) version of FORTH, and listed a simple program (set of FORTH definitions) for doing so. In respect to translation, there are three different classes of FORTH words:
(A) Those such as mathematical symbols which don't need to be translated.
(B) Words such as DO and IF which cannot be translated by a simple colon definition; the existing definitions must be re-copied and given German names. (all the definitions are short — one line — however)
(C) Other words, which could either be re-copied, or re-defined by a colon definition.
In any case, separate vocabularies can be used to prevent spelling clashes, no matter how many languages are spoken by one FORTH system. It can be possible to change languages as much as desired, even in the middle of a line.
The article stated that there was no run-time overhead. Such performance is possible, but the example given does have a run-time overhead of one extra level of nesting for each use of a word translated by a colon definition.
The following article by Bill Ragsdale is a more advanced treatment of language translation methods. It is written at the level of the FORTH systems programmer, and it uses a more standard FORTH version than the DECUS-supplied version which was used in the article which appeared in FORTH DIMENSIONS 1.
JOHN S. JAMES
FORTH LEARNS GERMAN
In the last issue of FORTH DIMENSIONS, we featured an article on natural language name conversions for FORTH, This article will add some additional ideas on the same topic.
First, the method shown (vectoring thru code) does have some run-time overhead. Also, some code definitions cannot execute properly when vectored in this manner, for example:
: R> R> ;
will pull the call of R> from the return stack and crash. We would ultimately like to translate names with:
1. Precisely correct operation during execution and compiling.
2. A minimum of memory cost.
3. A minimum of run-time cost.
4. A minimum of compile-time cost.
Let us now look at three specific examples to further clarify some of the trade-offs involved.
EXAMPLE 1 — COMPILING WORD
Let us see how UBER can be created to self-compile.
HEX : D-E >R 2+ @ (2+ optional on some systems) STATE @ IF (compiling) DUP 8 - C@ 80 < IF 2 - , ELSE (immediate ) EXECUTE THEN ELSE EXECUTE THEN ; : DO ENGLISH EMPLACE D-E ' , IMMEDIATE ; IMMEDIATE : UBER DO.ENGLISH OVER ; : LADEN DO.ENGLISH LOAD ; etc.
When building the translation vocabulary, the colon ':' creates the word UBER and then executes the immediate word DO.ENGLISH. DO.ENGLISH first emplaces the run-time procedure 'D-E' and then uses " ' , " to emplace the parameter field address of the next source word ( OVER). Finally, the new word (UBER) is marked immediate, so that it will execute whenever later encountered.
