Some easy ones (?)

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

What follows are ten proposals adapted from Steele's list of last
December.  These have been discussed before, and I believe that they
should not stir up much new controversy.  There are a lot of issues like
this, so I'm hoping that we can deal with these in batches, while
continuing to discuss more difficult issues like declaration scoping.
We shall see.  Please read these over and indicate any problems you
discover, or whether they all look OK to you.

The plan is to discuss these things for a week (or more if complexities
arise), then to put the proposals forth in their final form for a last
round of comments, and finally to send the proposals to the technical
committee, who will make the final decisions.

This is something of an experiment.  If we can't handle this many simple
things at once, we'll have to deal with issues in smaller batches, but
then it will take twice as long to settle these things.

-- Scott

---------------------------------------------------------------------------
Proposal #5: PARSE-BODY

Extension:

Add a new function (PARSE-BODY body environment documentation-allowed-p).

It pulls apart the body into three parts: a list of DECLARE forms, a
documentation string (or NIL if none), and the body proper.  These are
returned in the order body, declarations, and doc-string as three
values.  PARSE-BODY may perform macro-expansion (using the given
environment) in order to determine whether an initial macro-call expands
into a DECLARE form or documentation string.
---------------------------------------------------------------------------
Proposal #6: Parsing in &BODY

Change (could conceivably break existing code which destructures &body
arguments, but this should be rare as such destructuring is generally
too complex to do via the built in mmechanism):

Extend the syntax of an &BODY parameter to DEFMACRO to allow writing
&body (body-var [declarations-var [doc-string-var]]).  If only body-var
appears in parentheses, it means the same as a body-var with no
parentheses.  Otherwise, it means to give the original body to
PARSE-BODY (with documentation-allowed-p true iff the doc-string-var is
specified) and then bind the variables to the corresponding values
returned by PARSE-BODY.  This is purely a syntactic convenience for the
user of DEFMACRO so that he doesn't have to use &ENVIRONMENT and then
call PARSE-BODY himself.

Note: This extension is proposed only for &BODY, not for &REST, so &BODY
will no longer be exactly equivalent to &REST in a DEFMACRO arglist.

[Note: KMP has suggested the syntax (...&body body-var decl-var doc-var).
This does not break any existing code and would allow default and
supplied-p values for the three variables.  I (sef) don't think these are
important advantages, and I prefer the syntax proposed above, which is
less confusing to the eye -- my eye, ayway.  The proposed format is the
one we discussed on the mailing list earlier and seemed to be favored by
most people.]
---------------------------------------------------------------------------
Proposal #7:  TYPE-SPECIFIER-P

Proposed extension:

Add a new function TYPE-SPECIFIER-P that is true of valid type
specifiers and false of all other Lisp objects.  Note that the use of
DEFSTRUCT and DEFTYPE can change the behavior of TYPE-SPECIFIER-P over
time.
---------------------------------------------------------------------------
Proposal #8:  Clarifications to DEFCONSTANT

Clarifications:

Clarify that using DEFCONSTANT to redefine any constant described in the
Common Lisp specification is an error.

Clarify that if the user defines a constant, compiles code that refers
to that constant, and then redefines the constant, then behavior of the
compiled code may be unpredictable.  It is an error to execute such
code.

Clarify that it is not an error to issue a second DEFCONSTANT command
for an existing constant iff the new value is EQL to the old one.

[That last clarification has not been discussed previously, as far as I
know, but seems to be needed for reloading certain compiled code files,
etc.]
---------------------------------------------------------------------------
Proposal #9: Variable Name Conflicts

Clarification:

Specify that it is an error for two parameters (including supplied-p and
&aux parameters) in the same lambda-list to have the same (EQL) name.

[As previous discussion brought out, we could instead allow this case
with the last-bound (rightmost) argument shadowing previous bindings in
the same arglist, but this is certainly bad style and interacts in nasty
ways with the proposed change to the scope of declarations.]
---------------------------------------------------------------------------
Proposal #10: Forms That Allow Declarations

Extension:

Permit declarations before the body of a LABELS, FLET, or MACROLET.
---------------------------------------------------------------------------
Proposal #11: Contents of Tagbody

Clarification:

Specify that constant forms such as strings may appear at top-level in a
tagbody, but that only symbols and integers are considered to be tags.
It is an error to use anything else as the destination tag for a GO.

[Several forms of this have been kicked around.  This seems as good as
any.  The original issue was whether you could put something like a
string at top-level and, if so, whether you could go to it.]
---------------------------------------------------------------------------
Proposal #12: Unique Names For Tags

Clarification:

Specify that it is an error for the same (EQL) tag to appear more than
once in the body of a TAGBODY.  (However, a TAGBODY may have the same
tag as another TAGBODY in which it nests, in which case the tag in the
outer TAGBODY is shadowed, as already specified.)
---------------------------------------------------------------------------
Proposal #13: Structure Sharing in Arguments

Clarification:

Specify that the &REST or &BODY argument to a macro may be the very list
from the macro call, and not a copy, and therefore the user should not
perform destructive operations on it.

Similarly, a function that takes a &REST argument should not
destructively modify it because in some implementations its top-level
list structure might share with a list that the user gave as the last
argument to APPLY.
---------------------------------------------------------------------------
Proposal #14:  THE and VALUES

Clarification:

Specify that in (THE (VALUES ...) form), the form may return more
values, but not fewer, than the number of types specified in the (VALUES
...) form, and that any extra values are of unrestricted type.

Also specify that (THE type form) where type is not (VALUES ...) is
equivalent to (THE (VALUES type) form).
---------------------------------------------------------------------------