[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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>
- From: Jonathan A Rees <JAR@MC.LCS.MIT.EDU>