16
$\begingroup$

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.

$\endgroup$
5
  • $\begingroup$ How do we count bytes for code golf in such language? $\endgroup$ 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$ Commented May 29, 2023 at 20:28
  • $\begingroup$ I dunno, keywords always look orange to me... $\endgroup$ 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$ Commented Jul 20, 2023 at 22:34

3 Answers 3

Reset to default
12
$\begingroup$

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.
$\endgroup$
1
  • $\begingroup$ You could substitute styling, like bold, underline, or special typefaces, and size. $\endgroup$ Commented Jul 11, 2023 at 1:12
2
$\begingroup$

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.

$\endgroup$
0
$\begingroup$

The color is just a "mode" and can be easily replaced with any attribute, i.e.: bold/italic, font face, font size, e.t.c. (modern IDE almost always use this approach to represent syntax entities, the colorForth just does one step further in this direction).

The similar approach was used in Algol which defines "keywords" and "operators" that can be of any character sequences (even localized ones). In printed form "bold" or "underline" were often used to represent them as well as some character sequences were assumed to be "math" and "greek" symbols. The Algol standard worked with tokens, not with character sequences. C++/Pascal's digraphs/trigraphs fall in this category too.

So, returning to Forth the printable characters can easily be used to represent the "color dimension" (either unused ones in the range \x01-\x1F or used printable ascii ones). You may take a look at the "4p" by Helmar Wodtke who tried to mimic this approach using ",", "`" and similar one character prefixes/suffixes (reader macros in LISP arguably do the same - number/string/quote/backquote e.t.c.).

The main goal of Charles Moore was to remove the "STATE" context which required substantial bookkeeping in case of extending the language (which almost every Forth program does as the DSL writing is the primary method to program in Forth). So the STATE was removed altogether and it was replaced with the word-tied attribute. That's it. Actually you don't even need STATE's in regular Forth's as it can be replaced with a set of dictionaries and cross-compilation systems are often implemented this way (using a separate "target compiler" set of words which hides the regular ones).

Just think of color as a value of STATE attached to every word and it is just easier to remove such repetitions and replace them with the color.

New contributor
Alexander Konev is a new contributor to this site. Take care in asking for clarification, commenting, and answering. Check out our Code of Conduct.
$\endgroup$

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.