Proposal #5 status

[System Files <SYS@SAIL.STANFORD.EDU>]

Received: from SCRC-QUABBIN.ARPA by SAIL.STANFORD.EDU with TCP; 28 Jul 86  11:54:30 PDT
Received: from FIREBIRD.SCRC.Symbolics.COM by QUABBIN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 24586; Mon 28-Jul-86 11:39:35 EDT
Date: Mon, 28 Jul 86 11:40 EDT
From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
Subject: Proposal #5 status
To: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>, common-lisp@SU-AI.ARPA
In-Reply-To: <FAHLMAN.12226116535.BABYL@C.CS.CMU.EDU>
References: <FAHLMAN.12226116535.BABYL@C.CS.CMU.EDU>,
            <860727-200655-2208@Xerox>
Supersedes: <860728113936.2.DCP@FIREBIRD.SCRC.Symbolics.COM>
Message-ID: <860728114007.3.DCP@FIREBIRD.SCRC.Symbolics.COM>

    Date: Sun, 27 Jul 1986  18:23 EDT
    From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>


    Here is the first of the status reports on pending proposals.  This is
    culled from a lot of old mail; my apologies in advance if I missed some
    key suggestion.  I suggest that we use this as the starting point for
    further discussion of this issue (and similarly with the others) and
    that we try to converge on a final set of proposals for the technical
    committee fairly soon.  All of these summaries are from me as moderator;
    where I have seen fit in inject one of my personal opinions on some
    technical matter, that is marked.

    -- Scott
    ---------------------------------------------------------------------------

    There seems to be no opposition to the idea of PARSE-BODY per se.  There
    have been numerous suggestions about the exact form of the arguments and
    return values, and I have incorporated most of these suggestions into
    revised proposal 5A below: making the environment and doc-p arguments
    optional, reordering the returns into what some consider a more natural
    order, and returning the declarations as a combined list of
    decl-specs (as the book calls them), without the surrounding DECLAREs.

    One suggestion by Nick Gall is to add a declaration-allowed-p form.  If
    this is NIL, then PARSE-BODY has the task of ensuring that the body does
    NOT contain declarations.  Some people have responded that this
    functionality does not belong in PARSE-BODY.  (Speaking as SEF, I agree
    with this view.  Nick is free to pursue this further if he wants to,
    but I suspect that the idea is not going anywhere.)

    One complex issue is whether the body should be returned in its original
    form or with any macro-expansion that was computed while looking for
    initial decls replacing the original body forms.  (There will only be
    one of these, since the first non-declaration stops the expansion.)  One
    would like to avoid doing the work of expansion a second time, but
    sometimes it is necessary to get at the original body.  In 5A below, I
    propose a solution that may get get the best of both worlds: the body is
    returned in original form, but there are two additional return values,
    one indicating the availability of a macro-expansion for the first body
    form, and the other being that expansion.  (Two extra values are
    necessary because the macro might perversely expand into NIL after doing
    a lot of work.)
    ---------------------------------------------------------------------------
    Proposal #5A: PARSE-BODY

    Extension:

[I somewhat agree with Masinter.]

    Add a new function:
    (PARSE-BODY body &optional environment documentation-allowed-p)

    The default for environment is NIL, meaning to use a null lexical
    environment.  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?  I can think of one example where it
can make a difference, but it also shows that this argument is
misguided.  There are probably others in the same class.  The example
is multiple-value-bind, which takes declarations but does not take a
doc-string.  Now, a doc-string isn't illegal; a string doesn't get
interpreted as a string.  Consider these cases:
	(multiple-value-bind (a b)
	    (compute)
	  (declare (ignore a b))
	  "frob")
This is completely reasonable.  "frob" isn't a doc-string (even if doc
strings were "allowed") because there aren't any forms following.
	(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.
	(multiple-value-bind (a b)
	    (compute)
	  (declare (ignore a))
	  "frob"
	  (declare (ignore b))
	  (compute-something-else))
This IS an error, but since multiple-value-bind doesn't take
doc-strings, it will stop parsing when it gets to "frob" and you simply
have to let the implicit-progn handler figure it out.

    PARSE-BODY extracts the documentation string and declarations from BODY,
    expanding initial macros as necessary to determine if they contain
    declarations.  It returns five values:
[A lot of rationale is missing.]

    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?
    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))
??  I assume somebody has convinced themselves that the ordering or
separation of declares has no semantic meaning in CL?
    3. The remainder of the BODY argument, following any initial
       doc-strings, declarations, or forms that expand into declarations.
    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
??	
    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?

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?