RE: Macros Make Me Mad

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

Todd Proebsting wrote:
> Basically, macros cannot be trusted in the hands of people who
> lack very strong skills, discipline or taste.  I.e., you want them to
> have all three before being trusted with creating macros.

I think there's a fair amount of agreement on the above point.  It's a
variation of the point Jonathan Rees makes in
http://www.paulgraham.com/reesoo.html, about "discipline-imposing
languages":

> In a pack you want to restrict everyone else's freedom as much
> as possible to reduce their ability to interfere with and take
> advantage of you, and the only way to do that is by either
> becoming chief (dangerous and unlikely) or by submitting to the
> same rules that they do. If you submit to rules, you then want
> the rules to be liberal so that you have a chance of doing most
> of what you want to do, but not so liberal that others nail you.
>
> In such a pack-programming world, the language is a constitution
> or set of by-laws, and the interpreter/compiler/QA dept. acts in
> part as a rule checker/enforcer/police force.

So the question becomes, if macros are a dangerous feature in a
"discipline-imposing language" or a "pack-programming language", how should
we respond to that?  By eliminating macros entirely from those languages, or
by controlling them somehow?

Eliminating macros entirely seems like a big loss.  All you do is spawn an
entire industry of add-on tools (*cough* aspect-oriented programming
*cough*), and automatic generation of source code becomes a way of life in
your language, along with filling in of boilerplate code generated by
"wizards(tm)".  Your editor probably generates some source code for you for
certain operations, and various other tools also generate source code.  Your
cubicle farms sure do generate a lot of lines of code, but how much of it is
really needed, and how much of it should be being read or touched by humans?
It's exactly as if our compilers, instead of generating executable object
files, generated assembly templates which we had to fill in before running
the final code generation pass.  Imagine how inefficient it would be if we
all had to do this with every module we wrote.

Not having macros also prevents or at least significantly complicates many
kinds of third-party add-ons, since a major extensibility mechanism has been
eliminated.  Such a restriction might have an apparent commercial benefit to
a company that wants to keep a tight rein over a proprietary language, but
it's an illusory benefit - because at the same time, you reduce the possible
ways in which your language can be used, and restrict the ability of the
language community to help grow the language.  In an environment like that,
you might find that your language's development bogs down in a bureaucratic
community standards process, in which instead of allowing nice dispassionate
market forces to decide what features are really useful or not, you have to
get committee agreement on everything.

So, clearly not having macros is a bad idea!  (QED.)  Luckily, we're all
smart guys here.  Can't we come up with a more controlled way to support
macros?  I think we can.  In fact, there's already a model for this in PLT
Scheme, in which each module starts with a header which specifies a
"language", e.g.:

	(module my-module mzscheme ...

...where the third keyword above is the name of the language to be used to
compile the module.  This "language" may include a set of macro definitions.
By default, PLT Scheme doesn't prevent you from also defining macros ad-hoc
within a module, but imagine if such ad-hoc macro definitions were
disallowed.  (Afaik, this should be trivial in PLT Scheme - the "language"
definition would simply not export the macro definition keywords.)  A
project manager could then simply mandate that the language to be used
throughout a project would be mzscheme-with-acme-corp-extensions (or
c#-with-acme-corp-extensions, etc.)  The macro definitions that go into this
"language" can then be carefully vetted and controlled according to GAAP,
FDA and HIPAA standards, by a conference room full of pointy-haired VPs, so
that the CTO of Acme Corp. can sleep soundly in her bed at night.  Third
party libraries which provide syntactic extensions can be integrated in the
same way, i.e. via the project's approved "language".

> Are these technical reasons?  No.  But they are practical reasons,
> and ultimately I program practically.

So, if the reasons aren't technical, but more managerial (or whatever), then
surely they can be managed managerially, with a little technical help from
the language?

A completely separate question is how to provide a good macro capability to
a non-s-expression language, but that can be and has been done.

Anton