Macros are a build-your-own-language construct, but to a certain extent so are functions. I agree that one should try functions first, but would not go so far as to put macros in the same category as using eval.
I thought a lot of Scheme implementations define IF in terms of COND. Is there some reason you're pointing this out?
I should have been more detailed and noted that on the "by all means use it" vs. "if you think you need it, think again" continuum, EVAL requires IMO more justification than a macro. The source of my concern over macros is that when designing them, care needs to be taken to clearly communicate their semantics, which is best done IMO by following the established conventions of the language and whatever other macros the user is expected to be familiar with.
You pointed out one could achieve much the same result as the aif macro by using cond. I wanted to point out that cond itself is an example of the power of macros.
My point was more than one isn't usually missing much by being limited to writing hygienic macros. I don't think anyone is disputing the power of macros; it's the power/cost of hygiene violation that people are discussing.
Someone could give a "trust the programmer" argument for making unhygienic macros available in a language, but that nostrum is problematic because there are two programmers: the macro writer and the macro user. It's harder than you think to write a macro using DEFMACRO that always behaves the way a user might expect it to behave, and as a user of a macro, you need to wonder how hard the macro writer worked to protect you -- something that I don't like as a fan of black boxes.
http://www.schemers.org/Documents/Standards/R5RS/HTML/r5rs-Z...
Macros are a build-your-own-language construct, but to a certain extent so are functions. I agree that one should try functions first, but would not go so far as to put macros in the same category as using eval.