Colored Forth - September 24th, 2002
I've been playing around with Colored Forth (brainchild concept of Charles Moore) for around two years now. I've written my own system. I use it. It is unique in some ways and ordinary in others. I think the ideas behind Colored Forth are worth considering.
In fact, Colored Code really means Visually Distinctive Code. Color is simply the method of choice used by Chuck Moore and others to distinguish between various types of words in their source code.
In the simplest form, each blank space in the text is replaced with a Token that is then used by two programs. Firstly the editor uses the token to visually distinguish the following word from its neighbours, and thereby tell the programmer what sort of word it is. For example: red definition, green compiled word, white executed word, magenta number, blue comment etc. Secondly the compiler uses the token to decide what to do with the following word. For example: define it, compile it, execute it, make it a number, skip a comment.
There are benefits to both uses of tokens.
The programmer gains valuable contextual information about the code. Mistakes can be spotted easily. Compile and Interpret modes can be switched between at will with nothing more than a color change. Numbers are obvious as is their base. Some words are eliminated altogether by providing their functionality in a token.
The compiler compiles the code faster as the source is more compact and it knows in advance what to do with each word. Numbers are not sought after in the dictionary. No system STATE information is needed as each word provides its own. Error checking can be improved if required.
Ultimately, as in many experiments, the differences between Colored and ANS Forth simply throw up concepts and entice us to think. Visually distinctive code is not about forcing people to give up the more traditional methods such as plain text. It is not about saying this way is better or that way is old fashioned. It is simply about exploring another alternative in the hopes that something useful can be gained, or if nothing else, at least a good time can be had by those participating!
Flux's Color Tokens Color Key Action --------------------------- RED F1 Define GREEN F2 Compile WHITE F3 Execute CYAN F4 Decimal MAGENTA F5 Hexadecimal YELLOW F6 Address KAHKI F7 Postpone BLUE F10 Comment ---------------------------
green
Flux makes use of dual wordlists, MACRO and FLUX. The Macro wordlist contains all the immediate words, sometimes referred to as compiler directives, as they are executed at compile time. The Flux wordlist contains the general use wordset and is where new definitions are placed by default. As it probably should not be up to the programmer to know which words in the system are immediate and which are not, both Macro words and Flux words may be green. Hence words like IF THEN ; FOR NEXT are the same color in source as DUP DROP + /MOD. In contrast, Flux words may also be white while Macro words may not.
cyan and magenta
In normal Forth source a number can be used in both compiler STATE modes. ie, Outside a definition in interpret mode, where it is placed on the stack at compile time, and inside a definition in compile mode, where it is compiled as a Literal. In Flux, since each word bascially includes its own STATE information in its color, there is no system STATE variable. Therefore, how does the compiler know whether a cyan number is meant to be compiled as a literal or not?
If a cyan or maganta word is followed by a green space and/or word, it will be compiled as a literal.
This little rule was derived from early versions of Chuck's original Color Forth as documented on Jeff Fox's website. It works well and is infact not hard to work with. Usually, inside a green definition, you want numbers to be compiled as literals. They are almost always already followed by a green word (hence a green color token) and you don't need to think about it at all. Once in a while you may want to compile a number in another way, like two numbers together. For this special case you must manually insert a solitary green space following the first number. This results in an extra space in your source, but it is easy to see what is going on here at a later date, as hovering the Color Editor cursor over that space will show it up as green.
yellow
The yellow address token is a useful one. It returns the code field address, (equivalent of an execution token in Enth) of a word. For example making the word DUP yellow, is the same as saying...
' DUP
...in ANS Forth. There is a quirk. Bear in mind that this returns an address on the stack. As Forth programmers we know an address is just another number. Therefore, in Flux:
If a yellow word is followed by a green space and/or word, it will be compiled as a literal, just like a number.
There is another use for the yellow token. Consider a VARIABLE in ANS Forth. It is designed so that executing a variable's name will return the address of its contents (ie, its data field) from which one may @ or !. This requires each variable to contain a small fragment of code, or at least a reference to code elsewhere, which is run whenever the variable is called. In ANS Forth one may create a word that has the same behavior as a variable, by using:
CREATE MYWORD 0 ,
...whereupon MYWORD may then simply be called like any other word. In Flux, when a red word is first defined, it is simply like a label, merely a header pointing to its code elsewhere in memory. You can of course compile in a code fragment to make the new word behave like a varibale when called, or you can simply always refer to that word in yellow. All this is doing is using a Forth word like a pointer, rather than a code entry point. Why compile a code fragment to return the address of your data, when you can simply use the word's address for your data? Clear as mud?
white to green trasition
It is useful to move in and out of compile mode and interpret mode at will. In ANS Forth the [ square brackets ] are used for this. In color code we can simply change from green to white and back again. This is common in ANS Forth:
: DEFINITION ( - ) somecode ... [ some code and maths ] LITERAL ... somecode ;
The numeric result of whatever was done at compile time inside the square brackets is often immediately compiled as a literal. Because this rule so often holds, in color code:
If a white word is followed by a green space and/or word, the number on top of the data stack will be compiled as a literal.
These rules may sound a little limiting and complex to deal with right now. I certainly thought so when I started. But give them a go. It really is quite elegant IMHO. If you come up with a better scheme, I'm all ears :)
