colorForth, from Forth creator Chuck Moore, is a dialect of Forth where colour of the source text is semantically important. There is no typical syntax: programs are pure sequences of words, where the colour of the word indicates its role. In broad terms:

  • green words are ordinary function calls or number literals to be compiled;
  • red words define functions, like : in standard Forth, saving the instruction address under that name;
  • yellow words are function calls executed at compile time;
  • white words are comments to be ignored;
  • magenta words declare named variables;
  • cyan words are deferred macro calls.

There are no keywords, and no parsing, but the nature of every term is statically manifest. It is almost a visual language, but probably not quite, though a specialised editor is required to allow the programmer to choose the word colour while writing. You could argue the toss on that.

This approach is intriguing, but seems to be unique in modern languages, even within the space of visual languages. I'm interested in why that is.

I'd especially like to see any experience reports, case studies, or other results showing differences in programmer satisfaction, comprehension, accuracy, or speed compared to more conventional Forth text. If there are other non-colorForth systems that have taken or considered a similar approach—industrially, academically, or personally—any indications from those would also be welcome. If there is reason to believe that it is a helpful approach, just underexplored for whatever reason, that would also be useful, or the reverse; I don't want to limit things to just colorForth–Forth randomised controlled trials (though I'd love to hear about any of those!).

I recognise that colorForth is able to bypass parsing and so have complete compiler in "a dozen or so lines of code", but I am asking about the experience in the language, rather than as the implementor; it also primarily targeted a bespoke system that may have limited its own adoption, more than the paradigm's.

  • $\begingroup$ How do we count bytes for code golf in such language? $\endgroup$
    – alephalpha
    Commented May 29, 2023 at 10:36
  • 2
    $\begingroup$ @alephalpha Makes me want to design a golfing language where every program is just the letter 'a', but the precise color of that one letter encodes an entire Python script that indicates its behavior. $\endgroup$ Commented May 29, 2023 at 14:49
  • 1
    $\begingroup$ @alephalpha Code is saved in a packed binary format with the colour in the first few bits of the token, but Moore also likes to use six-bit bytes, so... $\endgroup$
    – Michael Homer
    Commented May 29, 2023 at 20:28
  • $\begingroup$ I dunno, keywords always look orange to me... $\endgroup$
    – Seggan
    Commented Jun 1, 2023 at 21:23
  • $\begingroup$ This is a reasonable question and shouldn't be casually dismissed - major popular IDEs - VSCode, IntelliJ, etc. - not allow allow, natively, a wide variety of colors to be assigned to a bewildering variety of syntactic and semantic constructs but also support, in their plugin "marketplaces", multiple plugins each written by people who think they can do it even better, and downloaded by people who agree. I don't get it myself, but apparently a lot of programmers like and even require what I consider useless "bling" so it should be taken seriously. (And then there are UI themes ...) $\endgroup$
    – davidbak
    Commented Jul 20, 2023 at 22:34

2 Answers 2


No research (there may be none or very little, especially since it's so unique), but I can think of a few disadvantages of using color:

  • Color-blind programmers will have a very hard time using the language.
  • You don't just need a special editor; version control is also harder because source code needs to be saved in a special format. This is a common problem for visual languages too.
  • It doesn't have the intuitiveness that many visual languages have. We are a bit familiar with it through the concept of syntax highlighting, but that's it.
  • $\begingroup$ You could substitute styling, like bold, underline, or special typefaces, and size. $\endgroup$ Commented Jul 11, 2023 at 1:12

The Advantages are Essentially Non-existent

The advantages that syntax-important colour could provide are essentially non-existent, as they can be handled better with text-only solutions.

Potential advantages and their limitations are:

Less code spent on syntax

Colour-syntax requires less characters to distinguish symbols.

Internally however, the colour change must still be represented, meaning there is still a memory cost. In colorForth, this is handled by bits appended to the Token. Additionally, adding the colouring requires a custom IDE and additional keystrokes or button presses, effectively completely removing this advantage.

More readable code

If colour implies functionality, then more code can be correctly understood with less context, not needing to seek for keywords or symbols which would imply the same information.

Unfortunately, there's very little additional context that can be provided whilst remaining easily distinguishable, especially for Colour-blind programmers. Additionally, the same colour-coding can and likely would be provided by any IDE with Syntax highlighting, which is a small ask when a custom IDE would otherwise be needed.

Is it Helpful?

The Disadvanteges presented by @Glorfindel, combined with the fact that most any advantage that can be perceived being dashed, suggests that colour-syntax is only harmful rather than helpful, the only real reason to use it is the Novelty.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .