Macros -> declarations

["Scott E. Fahlman" <Fahlman@CMU-CS-C.ARPA>]

Here's where my thinking is right now on all of this declaration stuff.

1. If it were up to me, I would still flush macro-to-definition
expansion, not because it is TOTALLY worthless but because the hassle it
causes far outweighs the marginal benefits.  However, I am willing to
concede that this battle is lost, and that this misfeature will stay in
the language.

2. Given that, we definitely need PARSE-BODY as an official part of the
language, and some advice on its use in the chapter on Macros (or
someplace).  The arguments would be (form environment &optional
(doc-string-allowed t)).  Query: when this form returns a body, is it
desirable to allow it to return a cons of the macro-expanded first form
and the rest of the body, or should we require the original body to be
returned?  Returning the expanded first form might sometimes save some
work, but I suppose you have to worry about things where some
optional-argument init code changes something that would alter the
macro-expansion.

3. I also think we should add KMP's extended syntax for &body, since
that makes it possible for Macro writers to pick apart these things
without having to explictly handle environments or even multiple values.
I prefer the simple syntax for this, as in (...&body (body decl doc)),
since it is less visually confusing (fewer nested parens) than the
version with defaults, and since I see no real use for these defaults.
But I could live with the more complex version, I guess.

4. We should give very serious consideration to eliminating local
special declarations.  We would add DYNAMIC and LEXICAL proclamations,
and phase out the use of the term "special variable" and the SPECIAL
proclamation.  (These would be changed in the 1986 manual, with a note
that this change has been made and advice that implementors handle the
phase-out gradually and carefully.)  There would be some style advice
that DYNAMIC variables should generally be dynamic thoughout a whole
program and should observe the *foo* convention.  The ability to switch
a variable back and forth from DYNAMIC to LEXICAL is provided mostly to
allow old code to be more easily ported to Common Lisp.  We might
possibly need something like the SPECIAL-LET that Moon suggested -- I'm
not sure.

In answer to KMP's comments about the usefulness of special declarations
in porting old code: 

Yes, clean language design and compatibility are natural enemies, as
most of us in this effort have seen many times.  Any one of us could
have designed a better Lisp if compatibility were not an issue.  On the
other hand, we explicitly decided that we would not shoot for full upward
compatibility with Maclisp or even for fully automatic translatability.
Some things were just too ugly not to change.

My own view of how compatible we want to be goes more or less as
follows: it should be possible to translate a program like Macsyma into
Common Lisp by having some competent programmer make a careful pass
through the code.  If there are things that just don't translate in any
reasonable way (leaving aside some of the godawful PDP-10 hacks that
occur at low levels in Macsyma), then we have diverged too far.  But we
should not feel constrained to have macsyma run in Common Lisp without a
conversion effort, and we certainly shouldn't feel constrained by a
desire to have the same source code run in other dialects of Lisp.

Of the specific problems that KMP raises, mostly having to do with
wanting to do big conversions a little bit at a time, I think that most
of these problems go away if we provide both DYNAMIC and LEXICAL
declarations.  I recognize that it is sometimes convenient to have such
declarations lexically bundled into the function definitions they
modify, but I see no reason why the proclamations and the definitions
can't be moved into a patch file together, as though they were
surrounded by one set of outer parens.  If you really care, there's
always PROGN to bundle these top-level forms together.  I think that
this would handle Masinter's objection, about passing a form from one
environment to another, as well.

Finally, on BSG's suggestion for extensions to the macro syntax, so that
we can macro-expand different types of forms in different namespaces.
Right now we've only got two such contexts, normal evaluated forms and
type declarations.  There was a proposal for a third type of context,
declaration subforms, but if we retain the Macro->declaration lossage it is
not necessary to add this.  I see no need to go to a more general
mechanism to combine the two existing uses of macro-like expansion.  I
also feel that if we do make this generalization, the pressure to
macro-expand new and bizarre kinds of things will increase over time.
SO I think we should table BSG's suggestion until such time as there is
a real need for it.

I've dumped all this stuff at once since I'm going to be off the net for
two weeks starting Monday.

-- Scott