[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Proposal #5 status
- To: common-lisp@SU-AI.ARPA
- Subject: Re: Proposal #5 status
- From: NGALL@G.BBN.COM
- Date: Tue, 29 Jul 1986 03:52:00 -0000
- In-reply-to: <860728114007.3.DCP@FIREBIRD.SCRC.Symbolics.COM>
- Sender: NGALL@G.BBN.COM
Date: Mon, 28 Jul 86 11:40 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Date: Sun, 27 Jul 1986 18:23 EDT
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
The default for documentation-allowed-p is NIL, meaning
that this form is NOT allowed to have a documentation string.
Can somebody PLEASE give me an example of (a) where this is useful and
(b) where this makes a difference?
As you point out, forms such as multiple-value-bind, flet, dotimes,
etc. are forms that 'are not allowed to have' or 'do not have'
doc-strings. Using your example:
(multiple-value-bind (a b)
(declare (ignore a b))
This is still valid. It isn't the greatest style, but there is nothing
wrong with it. "frob" is a constant compiled for effect. As I
understand the current proposal, calling parse-body on the above "body"
would result in an error, which is wrong. The argument should be called
no-doc-string-p. It directs the parser to >>stop parsing<< when it
encounters a doc-string; it doesn't tell the parser to signal an error.
You misunderstood the current proposal. Calling parse-body with
doc-string-allowed-p true, would return "frob" as the doc-string, and
only one form in the list of 'body' forms. Calling parse-body with
doc-string-allowed-p false, would return nil as the doc-string value
and two forms (the first being "frob") in the list of body forms.
This is how doc-string-allowed-p makes a difference for legal bodies.
1. A documentation string (or NIL if none is present).
Why isn't the body first. What if there is more than one doc string?
Because the order of the values reflects the order of the components
of a body. Why should body be first? There can't be two doc-strings.
The second string in a body is always considered a form.
2. A combined list of declaration specs, extracted from all
DECLARE forms found at the start of the body, whether present in the
body itself or obtained via macro-expansion.
This isn't explicit enough. Do I get
((declare (ignore a))
(declare (ignore b)))
or do I get
(declare (ignore a)
or do I get
You get the last alternative, 'a list of decl specs'; the other two
alternatives are declarations (which contain decl specs).
?? I assume somebody has convinced themselves that the ordering or
separation of declares has no semantic meaning in CL?
I assumed everyone had.
4. The macro-expansion for the first form in return value 3, if any.
Why the macroexpansion of the first form of the body? Why not the body
with the first form possibly expanded? Why should I always
,first-form-expanded ,@(rest body)
As was discussed, some macro expanders may want to see ALL body forms
(after decls and doc) before expansion, thus parse-body MUST return
all body forms unexpanded.
5. T if return 4 is a valid macro-expansion for the first form
in return 3, NIL otherwise.
What is an invalid macro expansion? What would this possibly be used
for? When could it possibly make a difference?
I suppose the same difference that the second value from macroexpand
Why not toss in the kitchen sink? It looks to me like
design-by-committee disease is striking. What functionality is useful
and needed, and what do we need to express it?
Ok, I'll bite, what?