[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Macros Make Me Mad



"Todd" == Todd Proebsting <toddpro@microsoft.com> says:

    Todd> Defining a macro is often an act of defining a language
    Todd> construct and implementing it.  Reasonably or not, I hold
    Todd> language constructs to a higher standard than, say, a mere
    Todd> function definition.

This idea gets to the heart of the disagreement. I think people who
are pro-macro don't see a strong distinction here. In fact they see
even a "mere" function definition as creating a new language
construct.

The idea of bottom-up programming seems to be that you intermix
defining your terms (language constructs) and using those terms to
express something, at successive levels of abstraction in a
program. You can take this approach in a language without macros or
even higher-order functions, but it's easier with them.

Smalltalk lacks many of the "built-in" language constructs found in
other languages, replacing them with idioms using higher-order
functions. This is made more palatable with concise lambda
syntax. Within limits, you can create new language constructs with
function definitions.

Perhaps it should be easier to create language constructs without
resorting to macros. Higher-order functions (with the help of concise
lambda syntax) cover a lot of macro cases. Perhaps explicit namespace
manipulation would cover a lot more. (Uses of macros for efficiency
reasons might better be left out of the picture.)

On the other hand, perhaps it should be easier to work with macros in
the same ways that we work with functions. If our programming
environments had good support for tracing through macro expansion,
flipping back and forth between the call and expansion of a macro, and
so on, perhaps the conceptual distance between macros and functions
would not be so large.

The argument that we should leave macros up to the experts sounds a
lot like the arguments that we should leave C++ operator overloading
or templates to the experts; it generalizes to "we should leave
abstraction up to the experts". No, we shouldn't--abstraction is for
everybody, and the lack of it is usually why programs are so bad.

Jake