I am of the opinion that if a language has macros, they should be a well planned out and integral part of the language and not of the compiler.

Example, Lisp's macro system is a very powerful integrated language feature and is subject to all the rules and regulations of Lisp itself.

Counter-example, C/C++ macro system is separate from the language and built into the compiler. The result is that you are not limited to the constraints of your language and can create invalid code and redefine language specific keywords.

At the end of the day, there are several languages that have no macro feature--but those fatures are not missed as much. It all depends on how expressive a language is, and whether it has alternative approaches to meta-programming. Meta-programming is just a way of ensuring that when you do X, X is done the same way all throughout the application.

C macros and Lisp macros are entirely different. C macros are expanded using string substitution before any other processing is done. Lisp macros are expanded after the input text has been parsed into a syntax tree1, and can use the entire language during expansion. With Lisp macros, you can not only do stupid things like #define begin {, but you can define your own control structures, and even populate arrays at compile-time using whatever code you want.

One reason for not including macros is that anything more complicated than simple string substitution can be very hard to work with in languages with C-style syntax. Another complaint about macros is that they can make code more difficult to read, which can be true if not implemented skillfully. Well-written Lisp macros can actually make the code easier to read.

1except for read macros, which are expanded during the process of creating the syntax tree.