Re: Proposal #5 status

[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)
		(compute)
	      (declare (ignore a b))
	      "frob"
	      (compute-something-else))
    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)
		     (ignore b))
    or do I get
	    ((ignore a)
	     (ignore b))
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)
    instead of
	    ,@expanded-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
could make.
    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?

-- Nick