Thanks for your comments. I have been referring to static code transforming macros. However, I want to go a step further, and eventually allow type manipulations within the macro language.

The Cat specification (which will be rereleased in a couple of weeks) will specify several different levels of Cat, which are each easily transformed from one into another. So one level of Cat will have the term rewriting strategies embedded, while the most basic version won’t. I’ve tried to clarify a bit more in a recent post at: http://cdiggins.com/2007/03/27/so-does-cat-have-names-or-not-and-does-it-have-rewriting-rules-or-not/

When I saw your presentation of the Cat language at the .NET languages conference in the summer of last year, I thought the most promising feature of Cat was the ability it gave the programmer to directly specify transformation rules within the language itself. (I have not looked at your most recent specification to see if this is still a feature; indeed, I’ve been disappointed that this point has seldom come up in your blog.) I talked to an engineer from Borland who saw the same presentation of Cat as I did. He agreed with me that the greatest feature of your language is the ability to embed transformation rules directly in the language. Working for Borland, the engineer often has to write transformation rules in the C++ compiler, but rather than having a special syntax and semantics, the transformation rules are hidden behind explicit C code and visitor patterns.

Looking back on it, I guess your transformation rules are nothing more than a macro language for Cat. However, if CLI and Cat can be converted into each other easily, then I think Cat could act as an excellent optimization tier.

You said this point is a brain-dump. Here’s my contribution to the mess. :)