> Except, of course, that doesn’t work. The preprocessor
> only makes one pass through the file, meaning a macro
> can’t call another macro.
macro.c:
#include <stdio.h>
#define LOOP(n) for (int i = 0; i < n; i++)
#define PRINT10 LOOP(10) { printf("%d", i); }
int main(void) { PRINT10; printf("\n"); }
gcc -Wall -std=gnu99 macro.c && a.out
0123456789
Ignoring his poorly protected macros, and taking nothing away from Lisp, am I missing some subtle point he's making, or is the author just flat out wrong here? I think he's just wrong, and this makes it hard for me to even read the rest of his argument.
A C macro can't directly -- nor indirectly -- refer to itself; even through other macro. You can't do loops, you can't do recursion.
(a nonsensical example, as I can't think of a proper one right now)
#define PRINTFOO PRINTBAR
#define PRINTBAR PRINTFOO
PRINTFOO
The ANSI C standard says a macro, while it is being expanded by the preprocessor, ``is painted blue'' (is no subject to further expansion).
I'm not sure, but probably it follows the C macros are not Turing-complete.
EDIT:
on the other hand, a LISP macro system is a Turing-complete programming language that's geared towards manipulating lists of symbols and values (which, incidentally, is LISP program).
Do you have a link for the "painted blue" reference? I agree with your explanation, but had never heard that particular phrasing and was intrigued by it. But searching on Google for things like 'expand ansi macro "painted blue"' returns only your comment and a scraped spam site of someone answering a similar question.
Ignoring his poorly protected macros, and taking nothing away from Lisp, am I missing some subtle point he's making, or is the author just flat out wrong here? I think he's just wrong, and this makes it hard for me to even read the rest of his argument.