Re: Some easy ones (?)

[NGALL@G.BBN.COM]

    Date: Mon, 21 Jul 1986  21:46 EDT
    From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
    To:   common-lisp@SU-AI.ARPA
    Subject: Some easy ones (?)
    Message-ID: <FAHLMAN.12224580594.BABYL@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.
Taking into account the other comments on this function (the ones that
I agree with at least), how about this proposal
(PARSE-BODY body &optional environment
                           declarations-allowed-p
                           doc-string-allowed-p)
Parses a BODY argument of the form
({declaration|doc-string}* {form}*)

according to the rules on page ????[Currently, incompletely specified
on pages 67, 153-154] and returns three values: a list of the
DECLARATIONs, the DOC-STRING (or NIL if none), and a list of the FORMS
(which may share structure with the BODY).  All the DECLARATIONs and
none of the FORMS will have been MACROEXPANDed and none of the FORMS
will have been.  The optional parameter ENVIRONMENT (which defaults to
NIL, which represents the null lexical environment) is used for such
macro expansion.

If the optional parameter DECLARATIONS-ALLOWED-P is true (the
default), then BODY may contain declarations and a doc-string.
Otherwise, if it is NIL, (in which case the argument to
DOC-STRING-ALLOWED-P must also be NIL) an error is signalled if there
are any declarations before the first FORM in BODY (or before the end
of BODY if there are no FORMs).

If the optional parameter DOC-STRING-ALLOWED-P is true (the default),
then the first string encountered before, during, or immediately after
the DECLARATIONs in BODY is returned as the second value.  Any
subsequent string is considered a FORM.  Otherwise, if it is NIL, then
all strings in BODY are considered FORMs.

[Rationale:
declarations-allowed-p is useful for ensuring that certain bodies do
NOT contain decls, e.g., the 'body' of CASE, PROGN, etc.

declarations-allowed-p=nil -> doc-string-allowed-p=nil since
currently, CLtL does not have ANY bodies that allow a doc-string
without allowing decls.

doc-string-allowed-p is shorter, and uses the correct terminology.

The order of the return values reflects their (typical) order in CLtL.

Decls are left expanded since it is unlikely that anything would care
about their unexpanded form; but the same is not true for forms, so
all of the forms are returned unexpanded.]

    ---------------------------------------------------------------------------
    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.]
How about a compromise?
&body may be follwed by a list of the form
(&forms {var|(var[initform[svar]])}
 [&declarations <<ditto>>
  [&doc-string <<ditto>>]])

Which means to give the list which would be bound by &rest to and the
environment that would be bound by &environment to PARSE-BODY (with
declarations-allowed-p true iff &declarations is specified, ditto for
doc-string-allowed-p) and then bind the variables to the corresponding
values returned by PARSE-BODY.

This is an upward compatible change (if a list whose first element is
NOT &forms appears after &body, it is destructured in the normal way.

Note that the &forms, etc., parameters may not be destructured [CLtL
should also put such a restriction on other defamcro parameters, e.g.,
&environment, but that is another proposal.]

    ---------------------------------------------------------------------------
    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.
I like the idea of a corresponding type-specifier named TYPE-SPECIFIER
(not TYPE).  I don't think a second value to indicate 'don't-know' is
necessary.  For example, if expanding a type-specifier signals an
error, then it is simply not a vaild type-specifier.
    ---------------------------------------------------------------------------
    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.
I would change "redefines the constant" to "redefines the constant to
a new, non-eql, value".
    
    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.]
Flush the last clarification.  My change makes it unnecessary when
talking about affected compiled code, and it contradicts pg. 56.
Finally, it makes it impossible to change your mind about the value of
a constant (before compiling any code).
    ---------------------------------------------------------------------------
    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.]
Specify same for LET, LET*, DO, DO*, FLET, LABELS, PROGV, MACROLET,
MV-BIND, and PROG.
    ---------------------------------------------------------------------------
    Proposal #10: Forms That Allow Declarations
    
    Extension:
    
    Permit declarations before the body of a LABELS, FLET, or MACROLET.
Fine.  That WAS simple :-).
    ---------------------------------------------------------------------------
    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.]
Fine.
    ---------------------------------------------------------------------------
    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.)
Fine.
    ---------------------------------------------------------------------------
    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.
I agree with the suggestions that returning or storing such a list
must be forbidden also.  Also, any kind of function/macro call
(regardless of how it was invoked) should be included in this restriction.
    ---------------------------------------------------------------------------
    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).
Since the VALUES type-spec is already allowed to contain &optional,
&rest, and &key,  I agree with DCP(?) that in
(THE (VALUES...) form), the form must return the 'required' values,
may return the &optional values, and any leftover values are discarded
by THE, unless &rest or &key is specified.  I prefer using &rest T to . T.
    ---------------------------------------------------------------------------

-- Nick