[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: email@example.com
- Subject: "Compiling CASE"
- From: firstname.lastname@example.org
- Date: Wed, 08 Apr 1987 15:49:00 -0000
- Cc: email@example.com
The problem cited recently regarding macros vs. special
forms contains some subtleties that need addressing. Certainly,
a compiler should be able to view a macro as a "special form"
for purposes of emitting efficient code. Sensing these is not user-visible,
and should be okay as long as the semantics of the language is not altered.
Problems arise when one uses code-walkers, or other code analyzers, that deliberately
expand macros in order to boil down all code to "the" small set of understandable special forms.
The program analyzer may do its transform, then compile the code. References to the original macro
will then most likely be lost.
In this case, the system in essence requires that such macros be expandable, AND that the
compiler be able to transform them for optimization. The two transforms may be very
different, so that compiling the macro-expanded code and directly compiling the macro reference
result in different emitted code.
Here are some alternatives to solving this problem; only the first appears to be in the
realm of a standards orginization:
1. Expand the set of special forms to include more of the built-in macros. Code walkers
would then obviously need work.
2. Require that all macro expansions be identical to the transforms performed by the
compiler. This, of course, is very hard to enforce since a compiler usually operates with
much more contextual knowledge than does a macro expander.
3. Ignore the problem. If a code-walker transforms code then compiles it, then it deserves
what it gets. Code walkers can optionally be improved to sense the "semi-special" forms.
The best solution, in my opinion, is (1), since it solves the problem completely:
there is no chance that different code sequences could be emitted due to a macro expansion,
thus retaining efficiency and avoiding subtle bugs. I realize that it is difficult to swallow
such a change, but it should be considered.
Note that the problem does not arise with functions, as they are of course not macro-expanded.
Thus, the compiler may transform them as it pleases and code-walkers are not affected.
Perhaps a study could be made to determine precisely which built-in macros are worth
making into special forms, thus reducing the size of the change. I would certainly vote for CASE
- Larry Stabile