RE: macros vs. blocks

["Anton van Straaten" <address@hidden>]

Trevor Blackwell wrote:
> Macros wouldn't have helped me write the functions like table and td
> either. In fact, I generated all these functions dynamically from a DTD.

So, you wrote some code (in Perl?) to generate Perl functions, using a DTD
as input?

If so, that code you wrote is the kind of code for which macros provide a
generalized abstraction.  I'm not sure why you say that macros wouldn't have
helped you; that's exactly the kind of thing they're intended for.  (Unless
I've misunderstood what you're referring to.)

However, this raises an important point: macros, at least Lisp/Scheme style
macros, are extremely closely connected to the code-is-data(-is-code)
philosophy.  If it was required that the functions you mentioned be
generated from an actual DTD, macros may not have helped as much.

If, however, it would have been acceptable to use your programming language
to define the equivalent of a DTD, then macros could be very useful, to
support the transformation of a DTD-like definition, embedded in your
program, into executable code.

In many languages, when data-driven things need to be done, the data which
defines the process has to be defined in some external format - XML, a DTD,
.conf or .ini files, etc.  A program must then be written to read this data
and react accordingly.  Such programs have to deal with parsing-related
issues and other things unrelated to the problem at hand.

In a code-is-data language, unless you have a really strong reason to use an
external format, it makes sense to instead define your data within the
language, where it is more easily processed and integrated.  Macros are one
tool which helps with that.  The ability to access your language's code
parser is another important factor.

Aside from the savings in the amount of code written, some of the benefits
of defining data within the language can be subtle.  For example, if done
properly, you can gain the ability to have the language runtime system, or
even the compiler, report errors in your "data files".

XML now serves a similar purpose for many programming languages without this
ability.  This was something Shriram covered in his presentation at LL1 last
year (http://ll1.mit.edu/shriram-talk.pdf).  In fact, that talk addressed
quite a few of issues currently under discussion.

In short, I think some of the difficulty in communicating the usefulness of
macros comes from how they integrate with other language features, and with
language philosophy.  The real question is not "should macros be
transplanted into language X", but rather, whether more fundamental
capabilities can or should be adopted and adapted by languages that don't
already have them.

Anton