[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Proposal #5, or somewhere around there (rather long, constructive, and non-flaming(!))
Alternate proposal that has a declarative syntax, and is probably a lot
[ &DECLARATIONS declares-var [ &DOC-STRING doc-string-var ]] &BODY body-var
If somebody wants to call it &DOCUMENTATION-STRING, go ahead; CLtL
usuually abbreviates "documentation-string" it to "doc-string".
- Since &BODY can only be used in macros, these extensions may
only be used in macros.
- &DECLARATIONS may only appear if &BODY appears.
- &DOC-STRING may only appear if &DECLARATIONS appears.
- If any of these extensions appear, they appear in the order given, on
the grounds that is the normal order found within code. It probably
makes parsing defmacro's lambda-list a bit easier, and uniformity
will make code easier to understand by other than the author.
- declares-var is a catenation of the declarations. If the original
(declare (ignore a))
(declare (ignore b) (inline aref))
then declares-var would get bound to
((ignore a) (ignore b) (inline aref))
- If &DOC-STRING is present, the first string of the unpruned body is
the documentation string, and parsing/pruning stops with the second
string, which is considered part of the implicit progn. [The
exception is a string that is the last form of the body, in that case
it is part of the implicit and not a doc-string, just like now.]
- If &DOC-STRING is not present, then the first string stops the
parsing/pruning of body. Any declares after a string are part of the
implicit progn and "are an error". Presumably the code that groks
implicit progns will complain about the presence of declares.
- body-var is the body without the declarations and/or doc-string, and
also with the first form NOT macroexpanded, even though
macroexpansion was necessary to search for declarations and
doc-strings. If the first form is a macro, it may get expanded
again. Tough, macros shouldn't have side effects.
I believe this nests correctly, as all the other defmacro destructuring
does. [Example deleted because even the simplest one is 16 lines long.]
I am willing to endorse this; I more-or-less believe it. I do not
believe the original
&BODY body-var [something-var [something-else-var]]
because it is totally lacking in syntax and comprehensibility.
Aside #1: I personally think &KEY and &BODY are mutually exclusive
because of their semantics; more-so when we worry about the presence of
declarations and a doc-string. This is because the semantics of a body
includes an implicit progn, whereas the semantics of keyword/values is of
markers and values. For those that do want &KEY and &BODY at the same
time it is probably necessary to require that the &KEY parsing happens
after the declarations/doc-string pruning.
Aside #2: If we had a simply specified PARSE-BODY, the simple
implementation of the above would be
(multiple-value-bind (declares-var doc-string-var body-var)
(parse-body original-body want-doc-string environment)
I think we should have a (simply specified) PARSE-BODY even if (some)
extension to &BODY is adopted. The compiler and special-form groker
need them for the same reason users want them for defmacro. I think
PARSE-BODY and an &BODY extension should look very similar to each
other. I believe the ideas in this messages show such a similarity.