<p><a href="https://colorforth.github.io/cf.htm" rel="noreferrer">colorForth</a>, from Forth creator Chuck Moore, is a dialect of Forth where <em>colour</em> 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:</p>
<ul>
<li>green words are ordinary function calls or number literals to be compiled;</li>
<li>red words define functions, like <code>:</code> in standard Forth, saving the instruction address under that name;</li>
<li>yellow words are function calls executed <em>at compile time</em>;</li>
<li>white words are comments to be ignored;</li>
<li>magenta words declare named variables;</li>
<li>cyan words are deferred macro calls.</li>
</ul>
<p>There are no keywords, and no parsing, but the nature of every term is statically manifest. It is <em>almost</em> 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.</p>
<p>This approach is intriguing, but <strong>seems to be unique</strong> in modern languages, even within the space of visual languages. <strong>I'm interested in why that is</strong>.</p>
<p>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 <em>are</em> other <strong>non-colorForth systems</strong> 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 <em>is</em> 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!).</p>
<hr />
<p><sub>I recognise that colorForth is able to bypass parsing and so have complete compiler in &quot;<a href="https://www.infoq.com/presentations/power-144-chip/" rel="noreferrer">a dozen or so lines of code</a>&quot;, but I am asking about the experience <em>in</em> the language, rather than as the implementor; it also primarily targeted a bespoke system that may have limited its <em>own</em> adoption, more than the paradigm's.</sub></p>

<syntax><language-ergonomics><colorforth>
Is colorForth's unique syntactic approach helpful to the programmer?
CC BY-SA 4.0
2023-05-29T10:36:16.697Z
How do we count bytes for code golf in such language?
alephalpha
CC BY-SA 4.0
2023-05-29T14:49:13.833Z
@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.
Silvio Mayolo
CC BY-SA 4.0
2023-05-29T20:28:40.060Z
@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...
Michael Homer
CC BY-SA 4.0
2023-06-01T21:23:51.417Z
I dunno, keywords always look orange to me...
Seggan
CC BY-SA 4.0
2023-07-20T22:34:59.583Z
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_ ...)
davidbak
<h1>The Advantages are Essentially Non-existent</h1>
<p>The advantages that syntax-important colour could provide are essentially non-existent, as they can be handled better with text-only solutions.</p>
<p>Potential advantages and their limitations are:</p>
<h2>Less code spent on syntax</h2>
<p>Colour-syntax requires less characters to distinguish symbols.</p>
<p>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.</p>
<h2>More readable code</h2>
<p>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.</p>
<p>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.</p>
<h2>Is it Helpful?</h2>
<p>The Disadvanteges presented by <a href="https://languagedesign.stackexchange.com/users/26/glorfindel">@Glorfindel</a>, 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.</p>

CC BY-SA 4.0
2023-06-01T23:53:32.877Z
2023-06-01T23:53:32.877Z
ATaco
<p>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:</p>
<ul>
<li>Color-blind programmers will have a very hard time using the language.</li>
<li>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.</li>
<li>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.</li>
</ul>

CC BY-SA 4.0
2023-05-29T10:18:38.097Z
2023-05-29T10:18:38.097Z
Glorfindel
CC BY-SA 4.0
2023-07-11T01:12:44.693Z
You could substitute styling, like bold, underline, or special typefaces, and size.
MicroservicesOnDDD
# Is colorForth's unique syntactic approach helpful to the programmer?
Posted by: username_0 on 2023-05-29
[colorForth](https://colorforth.github.io/cf.htm), 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](https://www.infoq.com/presentations/power-144-chip/)", 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.
**Tags:** syntax language-ergonomics colorforth
> **Comments:**
> **username_1**: How do we count bytes for code golf in such language?  
> **username_2**: @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.  
> **username_0**: @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...  
> **username_3**: I dunno, keywords always look orange to me...  
> **username_4**: 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_ ...)  
---
## 2 answers
### Answer by username_6 on 2023-05-29. Score: 12
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.
> **Comments:**
> **username_7** (2023-07-11): You could substitute styling, like bold, underline, or special typefaces, and size.  
---
### Answer by username_5 on 2023-06-01. Score: 2
# 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](https://languagedesign.stackexchange.com/users/26/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.
---
