click on it...

Biggest Orchestra Source File!

Recently due to some experiments, we began to use Racket in advance. What happened next was to need a good IDE to work with Racket. As you know this happens when we need a good place to work:

In the process of writing the language definition for Racket, one thing started bothering me: Racket has a very huge number of language keywords.

The list was horribly very long but due to the good tooling we have, it wasn’t so hard to manipulate it. I formatted the list of keywords into only words by replacing the cluster and then turned it into a regexp code in VS Code. Next part was escaping the dangerous stuff. I gave the very long regexp to Quartet Compiler (Orchestra’s reverse compiler that converts regexp into Orchestra code) and then just wished for it not to crash. The fun part was that: It worked! not a single bug, not a single mistake! I realized that I haven’t taken care of some minor escaping, fixed them manually and meanwhile sensed some minor degree of slowness in the Google’s Blockly. It was only when I exported the code into SVG that I realized why it was slow!

The rest of the story is even more interesting. What happened was that when I pasted the code into the tmLanguage file, Visual Studio Code’s regexp engine (which is V8’s regexp engine) broke! It was so big for it to be handled. That means: if we take this code as a smoke test, while Orchestra and all of its assets did awesome, V8 lost! That is both good and bad. It’s bad because now we know that RegExp is not that scalable after all and it’s good because now we know that even for the biggest possible RegExps, Orchestra works great without any problems!