We've already been over Lisp macros vs. C preprocessor. They are completely different animals so comparing them doesn't get us very far.
How they work or what they do isn't important, it's the function they serve. And both Lisp and C macros serve to extend the language, grow it and adapt it. The ability to do this, and do this as freely as possible is why Lisp is still around, and probably why it's more reasonable to ascribe it an open end
>>46
Speaking of loops, LISP is the only language where you have to invent new constructs to create loops, so this "use the macros to implement basic language features from 1960's" seems contrived
Assembler, Forth and a lot of functional languages would be a few other examples where Loops aren't primitive forms.
Either way, that's not important, precisely because Lisp can grow and adapt so organically. If someone were to just learn the basics of Lisp, without bothering to find out how it's implemented, they'd probably not even think that the various loop macros are not primitive forms.
>>47-48
I don't know what you're trying to prove here, you're assuming nobody else here has any knowledge of C. Of course you can do this. I didn't say that you couldn't define your own loops in C (you're on the level of dolist or dotimes) but ==loop=, that is it's own little language. What I want to see is a single macro in C that could compile something like
(loop for i upto 10
when (evenp i)
collect i)(loop for l in list
for a across vector
thereis (pred l a))(loop for i from 0 by 2
for sub on list
repeat 100
when (somefun sub)
sum (expt it i))etc. The examples don't make any sense, the point is that it's all one macro, that can be composed. Iterate would probably be an even better example, because it integrates into lisp more nicely, overall, and can even be extended, by the user.
A great talk on this topic, is Guy Steele's "Growing a Language" from over 20 years ago. It is a generally very interesting take on language design, if you care about this discussion or not.