[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: common-lisp%SU-AI.ARPA%u-tokyo.junet@CSNET-RELAY.ARPA
- Subject: &BODY
- From: yuasa%kurims.kurims.kyoto-u.junet%utokyo-relay.csnet@CSNET-RELAY.ARPA
- Date: Wed, 23 Jul 86 20:10:42+0900
Date: Mon, 21 Jul 1986 21:46 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
Subject: Some easy ones (?)
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.
This is confusing. CLtL (page 146) says that
Anywhere in the lambda-list where a parameter name may appear ...,
a lambda-list may appear in place of the parameter name.
Thus, the following is a valid DEFMACRO form.
(DEFMACRO FOO (&REST (X Y Z)) ...)
which is equivalent to
(DEFMACRO FOO (X Y Z) ...)
But a similar DEFMACRO form
(DEFMACRO BAR (&BODY (X Y Z)) ...)
is regarded as
(DEFMACRO BAR (&BODY X) ...)
if doc-strings and declarations are ignored. Thus KMP's suggestion below
is less confusing.
[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