Although the context (being on news.ycombinator) tends to make me think of Lisp macros, there is no reference to any language in the post's text. I believe c macros still count as 'macros'.
they're preprocessor macros. editor input recorders are also "macros", but they're editor macros. Lisp macros are not generic "macros", unless you're in the company of Lispers, but lisp macros :-P
If you want to explore the highest level of code transformation, grab a nice little book called "Term-Rewriting and all That".
P.S. It's actually not a nice book. It's a theoretical mindfuck that will have you chasing abstract algebra down rabbit holes. It took a good year of my life and I still have no clue. </confession>
Because C macros have no sense of context; they're replaced in the raw character stream while lexer is reading in a file. C macros are mostly stupid string-replacements of the s/foo/bar/g type.
Lisp macros operate on the abstract syntax of the code forms, after it's parsed. They're tree-transforms. They could also be nested, so one macro would operate on the result of another. All of them could also operate on the values read by reader macros, which are Lisp's C-like preprocessor macros: A lisp macro that frobs vectors could, for example, processes code that looks like any of the following: foo[], vector foo, (vector foo), (array 1 ..), etc. if the appropriate reader syntax is defined for them. That's right, ONE macro to do all that.
