Compile-Time Reflection: Metaprogramming in Heron
I have just released version 0.8 of Heron . This is a pretty significant version of Heron for me, because it implements a feature that I have wanted for a long-time: the ability to execute arbitrary code at compile-time and to modify the abstract syntax tree.
Version 0.8 of Heron has a number of small improvements and bug fixes, but the coolest new feature is the ability to execute arbitrary code at compile-time and to traverse the code object model. The code object model is a typed representation of the abstract syntax tree (AST). The Heron code object model is outlined inthis file.
In Heron any code in the program can be executed at compile-time or at run-time. There is no special syntax needed to identify code executable at compile-time.
This is made possible in Heron because the compiler has a built in interpreter which executes immediately after the input code is parsed into an abstract syntax tree. The only difference between compile-time and run-time execution is the entry point: where program execution starts.
In Heron the run-time entry point to a program (other than scripts) is by convention the constructor of a class named "Main". Program termination occurs once this is class is finished construction. At compile-time the entry point is a different class, this one named "Meta". (note: these conventions will probably change before the official version 1.0, because I should probably use static functions like C# and Java). The other difference is that the "Meta" class constructor accepts an argument of type "Program" which represents the root object in the code object hierarchy.
Another way to think of the Heron metaprogramming system is that it is a reflection system, but available only at compile-time. Unlike the reflection APIs available for C# (and I think Java) you can examine and modify code right down to the level of statements and expressions.
While the current version of Heron the metaprogramming is mostly limited to introspection (other functionality simply hasn't yet been tested, but may work), it already has a wide variety of potential uses. The first program I wrote to test it is a pretty printer, which outputs its own source code as text by walking the object model. You can see the source code here.
To test this program you canrun the interpreter with the test file from the command-line:
HeronEngine.exe tests/prettyprinter.heron
However, I see no reason not to write more interesting programs like source to source translators (e.g. from Heron to C), or even native-code compilers. I am especially interested in writing a Heron to JavaScript translator.
I may even write a static type checker using the metaprogramming system itself. I think though that once I have a Heron interpreter written in Heron itself is when things are really going to get interesting.
I'm not an expert in meta-programming or macro systems in other languages, so I'd be really interested to hear how this compares with other languages.

