[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Some easy ones (?)
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