[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Some easy ones (?)
- To: NGALL@G.BBN.COM, Fahlman@C.CS.CMU.EDU
- Subject: Re: Some easy ones (?)
- From: David C. Plummer <DCP@QUABBIN.SCRC.Symbolics.COM>
- Date: Wed, 23 Jul 86 13:08 EDT
- Cc: common-lisp@SU-AI.ARPA
- In-reply-to: <[G.BBN.COM]23-Jul-86 02:30:50.NGALL>
Date: 23 Jul 1986 02:30-EDT
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
Parses a BODY argument of the 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
Proposal #7: TYPE-SPECIFIER-P
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
I like the idea of a corresponding type-specifier named TYPE-SPECIFIER
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
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
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