On Jan 3, 2008 2:15 PM, Roberto Ierusalimschy <
roberto@inf.puc-rio.br> wrote:
As far as these descriptions go, there is no difference between macros
and subroutines (functions). The real "selling point" for a macro
mechanism is what you can do with its macros that you cannot do with
functions. And (at least for me) the real interesting question is *why*
you cannot do with functions what you can do with macros.
Macros are used for:
- micro optimization, by moving a couple of operations from runtime to compile time. Introducing macros for that is an overkill IMO, at least in Lua. The proper way to optimize bottlenecks is to fall back to C.
- adapting the syntax to Joe Random Hacker's arbitrary tastes. This sometimes shows Joe's complete lack thereof, and much more importantly, his disregard for readability of his code by other coders. It's often a sign that he doesn't care about maintainability, and that his code has therefore little chance to be maintainable. Useful criterion to spot code you shouldn't touch with a pole, though :)
- capturing different ways of thinking. If you think your program in a structured way and your language only has GOTOs and macros, it's worth defining for/function/while/if/switch macros to better reflect your program structure (OK, bad example, this can more or less readably be captured by function closures). Less ancient inventions (multiple dispatch, RAII, CPS transformation, structural pattern matching, advanced flow control without monadic goo...). The most extreme form of this is the design of full embedded DSL.
The boundary between gratuitous syntax tweaks and support for a new paradigm is not always obvious to trace (to take a recurring example, would a switch statement be carcinogen syntax sugar, or would it substantially improve readability?)
- if you extend the question from macros to full compile-time meta-programming, you can add static code analysis, to detect properties (usually defects or lack thereof) of your code.
