Re: Macros Make Me Mad

[Neel Krishnaswami <address@hidden>]

Todd Proebsting writes:
>
> Despite the fact that many folks I respect swear by macros, I've yet
> to feel comfortable with them in a language.  Since LL2, I've been
> trying to figure out what my resistance is based on.
>
> Defining a macro is often an act of defining a language construct
> and implementing it.  Reasonably or not, I hold language constructs
> to a higher standard than, say, a mere function definition. 
>
> Are these technical reasons?  No.  But they are practical reasons,
> and ultimately I program practically.  Macros may be great for
> individuals and small groups, but I just don't believe that they
> scale for these non-technical reasons.

For me, macros are a prerequisite for getting the leverage I need to
get Needle to where I want it to be.

My idea is that a lot of really powerful techniques -- combinator
parsing, logic programming, etc -- don't get used because users hate
extra downloads. If, say, 70% of the people with a need will download
the package that solves it, then adding a prerequisite package wil
drop the number of people willing to get both down to 49% of the
people with the need. That's no good. So they just have to be in the
standard library (this is the Java lesson).

Now, both of these are pretty easy to encode in a functional language
with higher-order functions: you can write a combinator library for
parsing and use call/cc to implement backtracking. However, while
these encodings are formally perfect, they aren't very much fun to use
because the syntax gets grotty. A library with a grotesque syntax,
even if it's in the standard library, won't get used nearly as often
as it should be.

That's where macros come in. They turn ugly syntax into beautiful
syntax. I plan on writing a GUI library which lets you use an
HTML-like hierarchical sublanguage to lay out widgets. And they can
turn *no* syntax into *some* syntax. For example, I also plan on
adding a SQL-like sublanguage, which will transparently get turned
into ODBC calls. The parsing process can do the checking needed on the
SQL, which the bare string-passing style can't.

All of this would be much more work and less flexible if I had to
modify the compiler to add each library. Now, I'll admit that I'm not
really addressing your question. I just don't know whether macros will
"scale up" -- I've never worked on a multi-million LOC project so I
have no frame of reference. But in some sense that doesn't matter,
because I can't reach my goals *at all* without them. Half a loaf is
better than none, surely!


Examples of good sublanguages:

o Schelog: Prolog in Scheme

  <http://www.ccs.neu.edu/home/dorai/schelog/schelog.html>

o DUIM: Dylan User Interface Manager

  <http://www.functionalobjects.com/products/doc/dguide/index.htm>

o Oracle PL/SQL:

  <http://info-it.umsystem.edu/oradocs/doc/server/doc/PLS23/toc.htm>

o Perl 6 parser patterns:

  <http://www.perl.com/lpt/a/2002/08/22/exegesis5.html>

-- 
Neel Krishnaswami
neelk@alum.mit.edu