[JarrettBillingsley]

So I've been thinking of adding an AST manipulation library to MiniD 2, which would allow you to:

1. Turn a string of MiniD code into an AST.
   
2. Manipulate that AST.
   
3. Build one from scratch.
   
4. Turn an AST into executable code.

Now, let's consider the utility of these things.

Items 3 and 4 can already be done, using string manipulation, loadString, and eval. In fact you could argue that they can be done more easily with string than with an AST library, because if you had a large block of code with only three or four small places to insert items, it would be much easier to do a couple string cats rather than having to build up an entire AST. Using strings is also nice because you can actually see the code, rather than a huge block of obtuse object instantiations.

The first and second ones really go together, because if you don't manipulate the AST of some code there's no point to turn it into an AST in the first place. The thing is.. I honestly can't think of how this would be useful in a dynamic language where Lisp-like macros aren't possible anyway. Any use of code rewriting would be contrived, ugly, and limited, since you can't access locals in dynamically-generated code anyway.

What I can't deny, though, is the utility of source code manipulation/profiling/whatever tools, as well as integration with IDEs and such. As such I've made the compiler a little more open, making all the class members of the AST nodes public, as well as unifying some classes so that everything can be represented by a tree of nodes derived from a single base class. Each node also has a type tag so you can do switches or hashes on the node types. This should make it at least possible on the D side to take some MiniD code, parse it into an AST, and do some kind of analysis/manipulation on it.

So that's it.