Some easy ones (?) -- 107 lines of answer (!)

[David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>]

#5, parse-body, looks reasonable.  Two comments:  I don't think you need
a declarations-allowed-p argument on the grounds that the semantics of
PARSE-BODY implies declarations.  What's the whole point?  Along the
same lines you don't need documenation-allow-p.  Don't you have to
return a list of doc strings?  I don't know if the BODY returned should
contain the macroexpanded first form in case it wasn't a declare.  Part
says yes, to avoid multiple expansion, part says no, on the grounds that
the compiler might have some knowledge of certain macros before they get
expanded.  (E.g., it might arrange for the fail case of CHECK-TYPE to
branch to the end of the function to allow the normal case to do
sequential execution, but the expansion of CHECK-TYPE might destroy the
semantic meaning.

#6: This just seems to random to me.  If you are really parsing a body,
you should be required to accept all three of new body, declarations and
documentation.  I'm under the impression there are relatively few macros
that actually have to use PARSE-BODY (but those that do really need
it!), and therefore this syntax doesn't have high visibility.  (P.s.,
(...&body body-var decl-var doc-var) will break a compile that isn't
prepared for it.)

#7: Why isn't (TYPE-SPECIFIER-P foo) == (typep foo 'type).  In other
words, why not define a type named TYPE that fills this gap instead of a
new function.

#8, DEFCONSTANT: Yes.  The last clarification is fine.

#9: Fine.  There is a 35% reasonable counter example, but I've been
getting too random recently.  Do you really want to say "is an error" or
"signals an error" when the compiler/interpreter tries to interpret such
code.

#10 declarations for LABELS, FLET:  Yes.  You may want to explicitly
state the a common such declaration is INLINE.  I can't remember the
reason for MACROLET.  Refresher?

#11 TAGBODY contents:  Yes.  The real issue is that tagbody tags must be
EQL, right?  The restriction to symbols and integers as tags and strings
being part of the program is much less confusing.

#12 TAGBODY tag uniqueness:  Yes.  Consider changing "is an error" to
"signals an error".  This is a compile-time issue, not a runtime issue,
so "signals an error" or "is an error and issues a warning" is more
appropriate.

#13 stack &REST lists: I don't think this is a clarification, it is a
changle.  [It would be nice if there were page numbers to go with these
clarifications.  This one is page 60 or so.]  The clarification is not
strong enough.  What is special with being called with APPLY?  Doesn't
the same clarification allow stack-"consed" &REST args?  That would
break some of the examples on page 64.  If you really want to "clarify"
this, you must specify that it is an error to destructively modify the
&REST argument, and it is also an error to return it or store it in
stable storage.  These restrictions have been complained about by
Symbolics customers for years.  I think they are also confusing (which
is why we get complaints), in that the programmer has to be very keen on
when and how each list is being used.  Consider this program
	(defun foo (&rest b)
	  (bar b))
All of a sudden, FOO has to know that BAR's first argument will not be
destructively modified or stored in stable storage.  This is highly
non-local to FOO.  This is not an easy thing to solve /efficiently/.
Sure, the compiler can insert a (setq rest-arg (copy-list rest-arg)) all
the time, but it shouldn't have to.

In other words, I vote no.

#14 THE VALUES:  Page 161?  I can't remember the discussion, but this
seems pretty random.  What I would prefer to see is a substantive change
here, which is along the lines of the following
	(the type form)
arranges to return exactly one value and it is of type type.  This is
similar to
	(the (values type) form)
If you want all the values, and the first is of type type, you say
	(the (values type . t) form)
If you want EXACTLY two values, you say
	(the (values type1 type2) form)
The implementation is responsible for adding or removing values that
FORM returns to return exactly two.  To do this today, one has to say
	(multiple-value-bind (a b)
	    form
	  (values (the type1 a) (the type2 b)))
or
	(multiple-value-bind (a b)
	    form
	  (the (values type1 type2) (values a b)))
Is this at all related to returning extra multiple values and using
multiple-value-call?  I can imaging a smart compiler that would turn
	(multiple-value-call
	  #'list
	  (the (values t t) (get-two-things))
	  (the (values t t t) (get-three-things)))
into efficient code that calls LIST of 5 arguments.  As the language is
currently defined, the above could return a list of any number of
elements, from 0 to <value-of-some-constant-i-can't-remember>.  What is
useful and what is really trying to be accomplished by this proposal?

=======

I think you better split things up.  Maybe its just me being to
talkative and/or flaming.  I'm quite fond of Common Lisp.  Really!  I
would like to see it do useful and reasonable things.  If a change
doesn't look like it does both, then I question its motivation.  #14 is
reasonable, but I don't see that it is useful, and I do see changes to
it that I think are also reasonable and are potentially useful for
programmers and implementations.