[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: email@example.com, firstname.lastname@example.org
- Subject: "Compiling CASE"
- From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
- Date: Thu, 9 Apr 87 11:33 EDT
- Cc: email@example.com
- In-reply-to: The message of 8 Apr 87 11:49 EDT from firstname.lastname@example.org
Date: 08 Apr 87 11:49:15 D (Wed)
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.
For the simplest code walkers and for purity/minimality of the language,
I don't find this acceptable.
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.
I think it is impossible. The compiler doesn't necessary "transform" a
multiple-value-bind form into source code; it probably generates code
sequences for it directly.
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.
Code walking should unduly affect performance, so I don't like your
second sentence. Your third sentence is the tip of an iceberg which I
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.
I have another alternative, which I believe is both better and harder to
implement. The problem is, what is a code walker? There's been some
mumbling about portable code walkers, but do they really solve any
cross-machine problems? Do people use code walkers for analysis (in
which case you don't have to keep the macroexpansions) or for
substitution (in which case there may be a problem)?
My proposal is to figure the functional needs of a code walker, and
document the interface in CLtL'91. Each implementation would be
required to implement the code walker. Each person therefore wouldn't
have to write his/her own, and there wouldn't need to be a portable one
because there is a "standard." I propose that the
code-walker-in-the-sky be allowed to have special knowledge of CLtL
macros that are implemented as special forms. There would be a keyword
argument saying to use the macro expansions instead. This means you
don't lose the benefits of treating some macros as special forms, but
you have to make sure that the functional needs of the code walker are
still met. I don't think this is an impossible task.
I use the Symbolics code walker a moderate amount, and it has many of
the above properties. It does a pretty good job. I would classify it
as a prototype and a reference point; I have been hampered by it.