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

RE: macros vs. blocks

Trevor Blackwell wrote:
> I would refine my macros-are-useless claim a bit: languages that already
> have syntax for things such as assignment, variable declaration, and
> quoted data (Python, Perl, Smalltalk, ...) don't benefit much from
> macros.

This incorrect conclusion comes from focusing too narrowly on small macro
examples, related to low-level language constructs.  The real benefit of
macros to an end developer is with application-level macros, where you
essentially get to build domain-specific languages for a lower cost than
just about any other approach.

When macros are used like this, they can "compress" code in a way that
ideally should result in a program with top-level semantics that are closer
to the problem domain, and further removed from low-level language
constructs.  This in turn provides greater leverage and improved

Can you simulate this with objects & blocks?  Sure.  But you can also
simulate objects in languages without them, like C.  That doesn't mean that
language support for objects is unnecessary.

One of the issues here is actually encapsulation: without macros, the
ability to create abstractions is limited by the degree to which underlying
language constructs peek through the abstraction barrier.  When implementing
an abstraction, like a class, choices are made about data types and the like
which aren't necessarily particularly important to clients of that class.
Clients must then use appropriate syntactic constructs when using the
object, although these may have little or nothing to do with the task being

Examples of this include the need to quote or not quote certain values, the
need to construct objects of other classes to pass through as parameters,
etc.  Macros help make the underlying implementation more opaque, and make
the interface easier to use - and remember.

If Python had macros, it wouldn't really need a project like Mobius Python
(http://sourceforge.net/projects/mobiuspython), which "supplements the
existing tokenizer and code generator modules with an extensible parser ...
intended for domain-specific Python supersets and to prototype extensions to
the Python grammar."

The LispMacroDiscussion that was referenced earlier has some discussion of
this kind of thing in one of the linked pages:
http://c2.com/cgi/wiki?LispMacroDiscussionTwo.  The example given there is
perhaps too simple, but it gives some of the flavor of what I'm talking