[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Misfeature: macros expanding into declarations
- To: Tim McNerney <TIM@MIT-MC.ARPA>
- Subject: Misfeature: macros expanding into declarations
- From: "Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>
- Date: Sun, 05 May 1985 16:18:00 -0000
- Cc: common-lisp@SU-AI.ARPA
- In-reply-to: Msg of 4 May 1985 19:26-EDT from Tim McNerney <TIM at MIT-MC>
- Sender: FAHLMAN@CMU-CS-C.ARPA
Although this "misfeature" makes life much harder on the Lisp implementor and
the macro writer, its semantics are not without utility. Let me illustate
this with a couple of simple examples:
If it were just a matter of making life harder on the Lisp implementor,
simple utility would probably be a sufficient argument. It is a fact,
lamented by some, that in the original Common Lisp design we were quite
willing to make the implementor go through incredible gyrations in order
to make things slightly more uniform or useful at the user level. This
has generally been accepted since, in many cases, this implementation
effort only had to be done once, in some public-domain implementaiton,
and all the others could then just copy the solution. It hasn't always
worked that way, but that was the motivation for letting certain
hard-to-implement things into the language.
This macro-expansion business is not just a one-shot implementation
problem, however. It is a rich source of bugs whose flow has shown no
sign of diminishing over time. It affects not just the hard-core
implementors, but anyone who wants to write macros or other source-level
tranformation or analysis tools. Not many people working at user level
understand everything you need to understand in order to do this right.
I'm not even 100% certain myself that a correct implementation is
possible. We keep finding subtle problems.
In addition to the problem of recurring bugs, it is clear that this is a
major contributor to poor performance in Common Lisp interpreters.
Given these problems, I think that we should only keep this mechanism if
people come up with important, non-imaginary uses for it that cannot
easily be done any other way. It seems a shame to keep such an evil
machanism in the language just because people can think up some clever
ways of using it.