Eddon does one thing that is really unique. It has no control statements or other syntax. This means that when you define things like classes, you are actually writing code. When you see “subclass”, it’s not a keyword, but rather a method that generates a class! Here’s how that works, and why.
The compiler will read through your file, generate the EDDON code, and then execute it! It then dumps the objects that were just created to a cache file. As long as the original source is not modified, we can skip the compilation. We run the code by creating an instance of an application object, which calls one of the methods we’ve compiled.
You have probably used languages that have preprocessors or definition formats like XML that generate the static portions of the code. Eddon generates static objects wherever it can and also lets you build objects through real code rather than using a separate language to accomplish this task. The EDDON syntax is specifically designed to make it this process very clean. You’ll see your actual variable and function names along the left edge of your editor rather than special keywords or types, and object creation is terse and simple. Keeping your code in a single language makes it cleaner and easier to maintain and the ability to use every feature of the language at compile time basically means you can control the compiler yourself. This can be done in other languages, but is usually not as straightforward.
Eddon also has a feature called “labels”. Normally a literal will be at the right-most of your statement with only statement arguments following it. If any token follows a literal, then Eddon takes this to be a label. A label is a simple method without arguments. The compiler takes the label to be a method and passes this method to the literal, replacing the literal with the result of the method call. The method used must not have side-effects and must guarantee that the same result is returned given a particular literal. A number of these are built-in, such as “ms”, “hz”, and “dB”. Multiple labels are interpreted from left to right. The general rule is that you always start at the direct object and work your way out.
Every double-quoted string in your code is placed into a file that is loaded at run-time. The index of the string is the Eddon hash of the string itself. The file may be translated and modified. The compiler will attempt to recognize when text content changes, and adjust the index hashes of translations if the default is changed.