Re: syntax

[Andy Freeman <ANDY@SU-SUSHI.ARPA>]

Jonathan Rees (JAR@MIT-MC) writes:
    ... I practically never see a legitimate use of a macro by anyone
    other than a language designer.

I haven't decided how to cover macros in my Common Lisp class, but I
recently abused macros.  I'd like to hear about other tools that would
have worked as well.

I've been studying coroutine and generator implementation techniques.
As part of this, I implemented Icon's control structures several ways.
My source programs are READable (as in, they can be read using READ),
unlike real Icon programs, but I'm lazy.  I didn't want to write code
to read them.  (I did write code to translate from my pseudo-Icon
syntax to real Icon syntax so that my test programs could be run by my
implementation as well as Arizona's real Icon implementation.)

I defined two macros to support this project.  The first one defines
procedures; its first argument is the procedure name, the second is
the argument list, and the subsequent arguments are the body of the
definition.  The macro translated this form into a block containing
several side effects to store the various translations I made.  (At
one time, I generated five different versions.)  Compiling a source
file containing procedure definitions saved the work of creating these
translations.  (Initially, these translations were very expensive,
often taking several cpu minutes for a small test program.)

The second macro I used did whatever was necessary to execute one of
the translation.  Some of the translations are native T code, so in
these cases, the macro expands to code that includes all of the
previously defined procedures.  In this case, compiling a file
(containing the macro) compiles the T code that implements the
program.  This is very important; it would be necessary even if I did
write code to read Icon programs and translate them.  (Yes, I could
write a T source file from the translations and then compile it, but
....)

One of the versions I generated used upwards continuations.  T doesn't
support them, but chez scheme does.  Therefore, I wanted my system to
run in both chez scheme and T.  The common subset of these two
languages doesn't allow procedure or macro definition, so I used
macros to define a larger common subset.  (Other differences were
filled in with procedures.)  The decision to use macros instead of
program to read and translate the pseudo-Icon programs helped here as
well; I didn't have to write common subset I/O code.

This isn't the first time I (or others) have pulled this common
language trick.  Once I convinced Interlisp and Maclisp to use the
same source.  Naturally this involved lots of hoops and whistles
(mapcar in the common dialect was called @mapcar), but it was workable
and used for a complete version of MRS.

These may not count as "good counterexamples", but macros made my work
possible.  <insert chain-saw analogy>

-andy
-------