Color Forth Myths

ColorForth has some controversy surrounding it. Much of it stems from a fundamental misunderstanding of the community beliefs held, in general, by the majority of its developers. This page aims to summarize many myths promulgated by those from outside the community, and address them, point by point, here.

0. ColorForth code snippets don't work on C2 Wiki since C2 Wiki doesn't support colors

Confirmed? (Now just watch as SamuelFalvo? raises a WebServer just so he can put up JPG images of ColorForth code snippets on the C2 Wiki...)

Other wikis support colors (and of course images would have to be generated via another site or person), so that wouldn't count.

1. ColorForth is useless for the ColorBlind

ChuckMoore is not color-blind; however, his eyesight is failing him as he ages. As a result, he built his language to cater to his particular sight issues: lots of bright colors to replace hard to read punctuation. The color unambiguously indicates the purpose of a Forth word, significantly simplifying the already pretty simple ForthLanguage compiler.

However, Chuck was very careful to mention that this concept, essentially using a different visual dimension to indicate a word's purpose, need not be restricted to color. There is no reason why fonts cannot be applied similarly. Indeed, anyone who has read the book, "Oh! Pascal!" would recognize the immediate value of PrettyPrinting. In this book, various typefaces indicate the various Pascal-related particles: keywords are in bold, italics used for (IIRC) comments, etc.

Personally over the years I've found PrettyPrinting with bold to be less readable than using SyntaxHighlighting with colored normal fonts. RobPike argues that PrettyPrinting is for fools in some of his literature (but I disagree). To some, it is debatable whether or not PrettyPrinting or SyntaxHighlighting is really all that much more readable (I think it does help a bit, myself).
It's interesting you mention this. I pretty much maintain this page, although I myself choose not to use ColorForth. While I love the idea behind it, I find it pragmatically challenging, precisely because I find forced color changes to be somewhat error-prone. I listed an example recently, towards the end of the page as of 2008-05-13, of reading a variable at compile-time and adding it to another value to form a range of values. This idiom is used all over the place in ColorForth code. However, although I'm not color-blind, I find the yellow-to-green transition hard to pick up upon when reading code. The chroma-Hamming distance just isn't big enough for me. :-) (OTOH, I love how it uses cyan text for eliding compiler markup like postpone! And it's very easy to see.) Hence, where possible, I prefer proper SyntaxHighlighting or PrettyPrinting while using a properly punctuated Forth. Of the two, I prefer SyntaxHighlighting over PrettyPrinting. --SamuelFalvo?

Applying this concept to Forth, and recognizing that Forth essentially has only three classes of words (defined, immediate, and compiled), plus two classes of numbers (immediate and compiled), we really only need five typefaces to reproduce the core essence of ColorForth in a purely monochrome environment. With just bold and italics, we get four of those right away. The fifth would be plain text.

 : convertFtoC   32.0 f- [ 100.0 180.0 f/ ] fliteral f* ;
 : convertFtoK   convertFtoC 273.0 f+ ;

convertFtoC 32.0 f- 100.0 180.0 f/ fliteral f* ;

convertFtoK convertFtoC 273.0 f+ ;

Additionally, it should be noted that color-blindness only impacts the ability to discern certain colors; it is not a total inability to see in color. While the particular colors ColorForth uses may be poorly-chosen for the color-blind (e.g. red and green), it is possible to carefully choose colors which are accessible to those with and without this condition. See http://jfly.iam.u-tokyo.ac.jp/html/color_blind/ for more information.

BUSTED.

2. ColorForth is just a glorified assembler.

This raises the interesting point that will occur repeatedly throughout any exploration of Forth: code only what you need. "Solve the problem you've got." Do the SimplestThingThatCouldPossiblyWork ... for you. In no uncertain terms, this means that Forth is tailored precisely to its audience and to the application you're working with; a dot-product of user and application requirements. Broadly speaking, there is no such thing as a language called Forth. Forth is what you start with. By the time the program is implemented, it isn't Forth anymore; it is now whatever language you've created to solve your specific problem with.

This is critical to understanding why Forth (and ColorForth) is the way it is. If YouJustDontGetIt, you'll never grok Forth or ColorForth. Guaranteed. I apologize if this sounds elitest, but there are things some people just can't wrap their heads around, no matter how hard you try, like HaskellLanguage's Monads, or AspectOrientedProgramming, or ... Forth's minimalism happens to be on this list. It is neither good nor bad; it just is.

With this background, ColorForth is clearly geared heavily towards highly customized, turnkey application solutions. Greater than half of classic ForthLanguage is usable from the interpreted command-line, providing for more interactive development. ColorForth is different; almost all of the language is implemented as compiler primitives now. Commonly used Forth primitives are included (via LOAD-blocks) into each application, just as C applications would #include headers for commonly used libraries. Looking at the sources for these, we find numbers and commas, the classic "place this number at the next location to compile" sequence of Forth instructions.

CONFIRMED

However...

The stack-based runtime environment provides the core of the MetaLanguage that is Forth, allowing the user to engineer his own language, starting at the assembly level, and potentially ending at artificial intelligence. ConcatenativeLanguages have properties similar to functional programming languages, and Forth is perhaps the best known ConcatenativeLanguage. Note, however, that Forth must not be confused for a real functional language.

3. ColorForth trades special characters for colors. This buys you nothing except problems in transferring code and printing ColorForth books and papers. There is no innovation in this idea.

ColorForth has, almost since it first was released to the public, supported importing and exporting of its source blocks to HTML. It is true that Chuck did not plan for this, since his projects are proprietary anyway. However, the community found that source code portability wasn't nearly the problem it was first made out to be.

BUSTED

4. A Filesystem is a necessity to write applications.

Files aren't needed in Forth. For some applications, they may be desirable; but it is important to distinguish need from want.

Blocks provide persistent storage analogous to orthogonally persistent operating systems today. In fact, their interface and modus operandi resembles closely how demand-paged virtual memory works in every major operating system today.

If you do need to access "files," as we know them now, you write a file system, in Forth, to access the relevant data. There are two approaches: one, if you're running ColorForth hosted under a "traditional" OS, you can write words which invoke the services of said OS. This is more a binding than a real driver, but the application code wouldn't notice the difference. On the other hand, if you're running on bare metal, where ColorForth really prefers to run, then you'll need to code the actual driver itself.

The second approach also has two subdivisions. One is to forego existing filesystems, and write your own. For example, a file is an ordered collection of extents, where each extent is itself an ordered collection of bytes. Supporting multiple files is pretty trivial, and writing a first-fit allocator of disk space isn't much harder than for RAM (although you will suffer a performance hit, since you're using a RAM-optimized algorithm for much slower disk storage). When you transfer whole cylinders to and from memory, instead of individual sectors, this approach might even make some sense. Directories can be implemented by using specially designated files, of the aforementioned construction, to map symbolic names to direct file references.

Advantages:

It is fairly simple to implement.
It works well with Forth's BLOCK system.

Disadvantages:

It won't be compatible with any other existing filesystem. This could be a show stopper.
It lacks fault tolerance (like FAT, it'll be prone to disk errors, power glitches, etc).

There is obviously a (one-time) time investment in writing this. The question the Forth coder must ask himself is, "Will it be faster to adopt a different persistence algorithm than to write using files?" If it is, and it usually is, it is time-wise cheaper to just use directly addressed storage. Experience with ExoKernels gives further evidence to this realization.

The other approach is to write a filesystem driver for an already existing filesystem. Modern filesystems are mostly engineered for performance and for fault tolerance, which of course are hard problems to solve. As a result, the amount of work necessary to make this happen is pretty formidable, and not one line of code written will ultimately contribute to the application you're really trying to develop.

As a result, ColorForth willingly ignores files. Most (but, admittedly, not all) applications can be re-engineered to rely on a different storage algorithm, and made to work with directly addressed blocks of storage. Since blocks mimic virtual memory processes, it follows that Forth software would work best with something like an ObjectOriented or a TableOriented? persistence strategy.

BUSTED

Moreover, ANSI Forth defines standard file access words which grants OS-independent filesystem access. Most Forth environments also provide more OS-specific words too, should you need them.

5. ColorForth editor needs to be replicated across all users to edit ColorForth source code.

Since the source is stored in a binary compressed manner with color tagging, this should be self-evident. However, the real problem alluded to is when you write customized color handlers, allowing for in-line graphical widgets representing higher-level program constructs. In other words, the color equivalent of macros.

To use a macro, one needs to have the implementation of the macro, expressed in terms of some base language. This much should be self-evident to the reader. Why should this be different, however, for ColorForth?

CONFIRMED

However

Even colorCoders may not be aware of the kernel word "class" that allows for changing the action, or adding to the current action of a class of colored words. ("Yikes! All green words blink now" sorta thing. --lol) Also, one should note that the creation of such a macro, the way the term is used above, to create a new color-type ( say sky-blue-pink for html ( better fml) tags ), one would mearly include this new code as colorForth bytecode, more likely colorForth/assembler-macros. In this way, any extention to the kernel requireing a re-compile in an assembler is basically unnecessary for a kernel update to a user of custom kernel code written by someone else.
Speaking of colorForth kernels:
- It should also be noted that colorForths are begining to appear with the kernel written in colorForth in the bytecoded section of the image. This is convenient to them that like to do things in the kernel. Should I want to change the way your kernel is going to run my code, then you and I will come to some agreement as to how to included my code to this colorKernel, and you could just load my code in at the proper juncture. Or I would document the idea, and you could add the changes into your colorKernel and move it to the head of the disk and cold re-boot. --Ray St. Marie

6. ForthLanguage (including ColorForth) lacks parameter passing

Forth has zero problems passing parameters. In fact, it excels at it, since the data stack is a first-class programmable object, as is (QUITE unlike any other language) the return stack.

If Forth couldn't handle parameter passing, how is it able to execute "1 2 +"? The data stack is used for all parameter passing and returning one or more results, if any.

BUSTED

One question from ColorForth, prior to refactoring, was, "As someone who isn't too familiar with Forth: How well does Forth handle complex parameters? e.g. if someone wanted to, say, write an XSLT processor in FORTH, how would one pass to it the XML data, the XSL data, and get back the transform result?"

In Forth, as in C, complex structures are best passed around as pointers to things. Strings, and other arrays of stuff, for example, are expressed as a pair of numbers: a pointer to the first character/element of the string/array, and its length. Parsing source text, for example, is done without ever modifying the source string in memory. Since pointer arithmetic is world reknowned to be burdensome, error-prone, and just plain fickle, most Forth modules hide pointer arithmetic behind higher level words.

7. ForthLanguage (and ColorForth) is not an option for professional software development

Forth is used in a professional context all over the world. FedEx's hand-held "Sign this please" devices are powered by Forth, for example. ChuckMoore uses ColorForth to write his custom VLSI CAD program, OKAD, which he uses to design custom chips, including his asynchronous Forth processors. He also uses ColorForth for general problem solving. Intellasys, Inc. is now making the first shipments of SeaForth?-24A 24-core MISC chips available. See http://www.intellasys.net/ for more information.

GE also makes fiber-optic telecommunications switches which are run on Forth. See http://www.forth.com/resources/apps/app-GE-Multilin.html

BUSTED

That being said, you need to consider your market as well. If most of the folks writing desktop applications are using C++, and you're writing a desktop application yourself, then there is a good chance that you might want to consider using C++ too. The odds of success in employing Forth in a C++-dominated world are pretty slim. You can do it, and it has been done before. But, why?

8. You can't print ColorForth

You will be hard-pressed to find a monochrome printer in most office supply stores these days. I should point out that Chuck Moore used to give presentations on ColorForth using self-printed ColorForth text on transparencies, using a Hewlett-Packard color inkjet printer.

BUSTED

8b. I meant in a magazine.

OK, well, this is a valid claim. Be specific next time. :)

Seriously, this boils down to the same basic argument about color-blind folks being somehow exempt from using ColorForth. PrettyPrinting in monochrome literature has been with us almost since the first printed source code listing. See myth 1.

BUSTED

9. You can't transfer / email ColorForth code

ColorForth code is transferable as well. At the very least, you can tar/zip up the raw sectors, and transfer it that way. More practically, however, it can be expressed naturally in ASCII using XML or HTML format.

BUSTED

10. System access in ColorForth is hard/impossible.

Every Forth environment I've used, from Commodore 64 on up to those running under Linux, allows me to exploit system resources. Many of them even allow me to add my own assembly code in the rare event that Forth doesn't already provide a systems interface to some resource.

BUSTED

11. ColorForth has no point to its existance.

This is not for you to decide. ChuckMoore invented it for his own purposes, and other people have similar feelings to Chuck on how bad the state of current software is today.

BUSTED

12. ColorForth is nothing more than syntax-highlighting and PrettyPrinting.

ColorForth uses colors to inform the interpreter what, precisely, it needs to do with a word. For example, a rather historic word index is used to print line 1 of a range of screens on disk. Since each screen characteristically starts with a comment describing the purpose of the screen, it follows that this word produces a kind of directory listing.

When actually defining the word index, it will appear in red.

When actually executing the word at compile-time, it will appear in yellow. For example, there is some confusion to new ColorForth programmers over the utility of macro-words (formerly known as "immediate" or "compiler" words in ForthLanguage). The precise behavior of macros can be emulated by defining words in the Forth vocabulary, and invoking them at compile-time by making their color yellow explicitly. This is often performed to evaluate constants. For example, let's say we want index to render a screenfull of lines at a time. We could write this (I'm using punctuated ForthLanguage as an example, due to this wiki's lack of color support):

 index dup scrhgt @ + range ;

In the above snip, dup is compiled, since it appears "normally" in green (see below), while the phrase "scrhgt @" would occur at compile-time because it would appear in yellow. Hence, on the data stack would be a precisely known integer value. Then, because we transition back to green for the subsequent words, the interpreter "just knows" to compile the value on the stack as a literal before continuing with other words. Contrast this with traditional ForthLanguage syntax:

 : index   dup [ screenHeight @ ] literal + range ;

When actually compiling a call to the word, it will appear in green. We have seen an example of this above.

When actually compiling the word into another definition, it appears in cyan. This doesn't make much sense unless you're writing a macro definition, but that's to be assumed. For example, ColorForth lacks a begin/while/repeat construct. ( UPDATE: this is no longer the case as colorForth2.0a does have begin/while/repeat included -- rastm2) However, it can be implemented relatively easily. Let's assume someone already implement ANSI-Forth-style if/else/then words. Then:

 macro
 begin here ;
 while  ansi-if  swap ;
 repeat  branch then  ;

Contrast this with:

 : begin  here ; immediate
 : while  postpone if swap ; immediate
 : repeat postpone branch postpone then ; immediate

Thus, what we see in ColorForth is not mere syntax highlighting. The colors serve a purpose intrinsic to the semantics of the language itself. It doesn't exist solely for the user's benefit.

However, ChuckMoore decided to explore ColorForth, in part, because he has failing eyesight, and precisely because he recognized that tagging each word explicitly with its stated purpose (best visually rendered via color, although typeface could just as easily be used) would make the program clearer. This serves a practical purpose: by removing the need to even enter "markup" words like [ ] : and so forth, he is able to make his font-size larger without reducing the amount of content and context viewed on his screen. Note that syntax highlighting never removes tokens from an input stream -- it merely colorizes what is there based on structural knowledge.

The difference lies in explicit-vs-implicit coloring information. With ColorForth, the programmer always determines the color of the word, since that directly affects how the word will be interpreted at load-time. With traditional syntax highlighting, the editor uses statically-determinable structural information about the program to render the colors.

The race is close, but I'd have to vote BUSTED.

CategoryForth, CategoryOperatingSystem