As well as consuming Haxe AST fragments, macros can have compiler-managed dependencies on external files. We have an Omnigraffle parser that can run within the macro environment and do some simple code generation from diagrams.
He mentions macros briefly, but they are certainly worth noting more prominently.
FWIW, the AS2 target is also quite solid. I did a lot of haxe programming targeting AS2 when I was working for chumby and we were using AS2 long after the rest of the Flash-using world had moved on to AS3. haxe was a lifesaver because AS2 was a lot more terrible than AS3 (IMO).
I had a very complete reactive UI layout and data binding system similar to the one in Flex but written in haxe, mostly using macros.
The UI was described in XML like:
<Panel id="rootPanel">
<Panel id="header"
width="{rootPanel.width}"
height="{rootPanel.height * 0.1}">
... (bunch of header controls described here) ...
</Panel>
<Panel id="content"
width="{rootPanel.width}"
height="{rootPanel.height - header.height}"
y="{header.height}">
... (bunch of content controls described here) ...
</Panel>
<Code>
... (bunch of arbitrary haxe code pulled into the class the XML is describing) ...
</Code>
</Panel>
The macro system would, at project build time, pull in all the XML files, look at the attributes, figure out which ones had dynamic data binding and would set up closures for them which would register to be called if any of the data items they depended upon were changed. Since all of this was set up at compile time using the haxe macro system, the app developer didn't have to worry about it when dependent properties changed, it just worked like magic. (Though it also did have a runtime API so the developer could register a closure to be called if particularly object properties were modified).
This is of course all very similar to what Flex did with code generation and data binding but the system was much lighter-weight as it was implemented in haxe itself and the macro system allowed it to do a lot of fancy type determination that kept the overall logic quite simple.
It could target AS3 or AS2 prior to the end of working on it since we did eventually ship a beta firmware for chumby devices to run ActionScript3/FlashLite4 code.
I haven't really had occasion to use haxe since, but I highly recommend it to anyone who would otherwise be stuck using the 'native' languages of a runtime like Flash or JavaScript.
As well as consuming Haxe AST fragments, macros can have compiler-managed dependencies on external files. We have an Omnigraffle parser that can run within the macro environment and do some simple code generation from diagrams.