In my 2D esolang, Trilangle, most instructions are a single character, which makes syntax highlighting trivial. However, the "push" instructions are two characters each, which complicates things.

Consider the following subprogram:

   .   .
    . .
. . > _ . . 
   .   .
  .     .

The two characters on the bottom (>_) can have a different meaning depending on the direction that this is approached:

  • If this is hit from the northeast, "> is a push instruction.
  • If this is hit from the northwest, "_ is a push instruction.
  • If this is hit from the west, southwest, or east, > changes which direction the IP is moving (and _ is a no-op).
  • If this is hit from the southeast, _ changes the direction the IP is moving.

2D languages with a "string mode", such as Befunge, have a similar problem. In fact, it's possible for every non-quote character in the program to be both an instruction and part of a string (example).

How can syntax highlighters for these languages determine what to color as string/character literals?


2 Answers 2


I think your language needs a dedicated editor, or at least a mode or plugin that goes beyond just highlighting characters. You can have different perspective that highlights different directions (in Southwest view, you see the sequences of characters highlighted specially), and the programmer needs to switch from one view to another to see how the program is structured.

Maybe you can have a main view too: if you imagine each perspective as being a transparent layer, you can combine the different highlights in the main view, assuming this does not result in too much noise.

  • 1
    $\begingroup$ That points at the general problem I have with syntax highlighting: I don't actually care about the syntax. I want semantic highlighting instead. (No to mention that some popular "syntax" highlighters actually only do lexical highlighting.) $\endgroup$ Jul 22, 2023 at 2:31
  • $\begingroup$ @JörgWMittag yes exactly, there are more categories of expressions to highlight than just keyword/function $\endgroup$
    – coredump
    Jul 22, 2023 at 3:01
  • $\begingroup$ It will definitely need a dedicated editor because traditional IDEs' concepts of implicit indentation for lines, bracket balancing, etc. will be complete nonsense. Even the assumption of typing left to right and then hitting return and going to the next line isn't necessarily very useful for editing such code. $\endgroup$ Jul 22, 2023 at 6:03
  • $\begingroup$ @KarlKnechtel This is a very good point! I honestly have a better time editing Trilangle code in notepad.exe than a traditional code editor precisely because it doesn't do those things. $\endgroup$
    – Bbrk24
    Jul 22, 2023 at 12:52

There are a few problems here.

First, parsing in a "traditional" language goes in only one direction, but in your language it can go in many directions. The well-trodden parsing theory (grammars, LL/LR, etc.) won't help you here.

Second, syntax highlighting your language isn't even possible if there are instructions which conditionally change the "cursor", because that means an instruction can be interpreted multiple ways at runtime. And even if you restrict highlighting to instructions which can only be interpreted in one way, finding them all is equivalent to solving the Halting Problem.

Nonetheless there are 2 approaches you could take:

  1. Use abstract interpretation to "run" your program, but instead of actually running and performing side-effects like printing, just color each instruction. The upside is that coloring will be accurate and you can give multi-meaning symbols a "multi-meaning" color. The downside is this is tricky and slow, and you won't be able to highlight everything because you'll need to guarantee a fixpoint.

  2. Simply highlight all the symbols which look like instructions. For instance, if you see a " next to a >, treat it as such even though the " or > could be executed alone, or backwards. This is the Word Search problem (LeetCode, Stack Overflow answer), in your case modified for a hexagonal grid. The upside is that this is easy and fast. The downside is that you're misleading users if the instruction isn't actually hit from the right direction, which may be more likely if your language/programs are small, because many times separate symbols will just coincidentally be together in the same way as an instruction.

Both of these have major downsides. To address them:

  • You could make it so there are no instructions which conditionally change the cursor (perhaps instead they conditionally turn the cursor "on" and "off" or change what actions are executed), so that all instructions are unambiguous.

  • You could make all symbols which are part of multi-symbol instructions, only part of multi-symbol instructions, and then disallow 2 multi-symbol instructions from sharing the same symbol. This would make it so each symbol can only be parsed as one type of instruction, or as a runtime error.

But, since you're writing an esolang, IMO you really don't have to worry about accurate syntax highlighting or large-scale performance. You could just pick approach #1 or #2 and go with it :)


You must log in to answer this question.

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