Re: Some easy ones (?)

[David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>]

    Date: 23 Jul 1986 02:30-EDT
    From: NGALL@G.BBN.COM

    Taking into account the other comments on this function (the ones that
    I agree with at least), how about this proposal
    (PARSE-BODY body &optional environment
			       declarations-allowed-p
			       doc-string-allowed-p)
    Parses a BODY argument of the form
    ({declaration|doc-string}* {form}*)
	...

Until somebody says something profound to change my mind, I hold that if
a "body" may not contain either declarations or doc-strings, it is not a
true body, and therefore you have no right to call PARSE-BODY.  I have
no idea what the reference to CASE and PROGN was.  If the claim that
each clause of a CASE contained a "body" you are wrong; it contains an
"implicit PROGN".  Implicit PROGNs are not suitable arguments to
PARSE-BODY.

	Proposal #7:  TYPE-SPECIFIER-P
	
	Proposed extension:
	
	Add a new function TYPE-SPECIFIER-P that is true of valid type
	specifiers and false of all other Lisp objects.  Note that the use of
	DEFSTRUCT and DEFTYPE can change the behavior of TYPE-SPECIFIER-P over
	time.
    I like the idea of a corresponding type-specifier named TYPE-SPECIFIER
    (not TYPE).
You're right.  Friendly ammendment accepted.
    I don't think a second value to indicate 'don't-know' is
    necessary.  For example, if expanding a type-specifier signals an
    error, then it is simply not a vaild type-specifier.


	Proposal #13: Structure Sharing in Arguments
	
	Clarification:
	
	Specify that the &REST or &BODY argument to a macro may be the very list
	from the macro call, and not a copy, and therefore the user should not
	perform destructive operations on it.
	
	Similarly, a function that takes a &REST argument should not
	destructively modify it because in some implementations its top-level
	list structure might share with a list that the user gave as the last
	argument to APPLY.
    I agree with the suggestions that returning or storing such a list
    must be forbidden also.  Also, any kind of function/macro call
    (regardless of how it was invoked) should be included in this restriction.

That may have been my suggestion, but there was a lot of other stuff I
said that this whole thing is a cop-out.  I think not being able to
destructively modify it is equivalent to not being allowed to store it
or return it.  (More on this in the next piece of mail.)  This leads to
very unintuitive behavior and hard/very-hard/very-very-hard to find
bugs.  How do you KNOW if the argument is somebody's apply arg.  See
next piece of mail.

	Proposal #14:  THE and VALUES
    
	Clarification:
    
	Specify that in (THE (VALUES ...) form), the form may return more
	values, but not fewer, than the number of types specified in the (VALUES
	...) form, and that any extra values are of unrestricted type.
    
	Also specify that (THE type form) where type is not (VALUES ...) is
	equivalent to (THE (VALUES type) form).
    Since the VALUES type-spec is already allowed to contain &optional,
    &rest, and &key,  I agree with DCP(?) that in
    (THE (VALUES...) form), the form must return the 'required' values,
    may return the &optional values, and any leftover values are discarded
    by THE, unless &rest or &key is specified.  I prefer using &rest T to . T.

I'll have to think about this.  I just responded to RAM going along with
his contention that THE is a declaration and should not change the
runtime semantics.  I the last 10 minutes of thinking about this issue
I still agree with him: THE is for declaratative purposes, not
procedural purposes.  On the procedural side, I suggested a TAKE-VALUES
form.