[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
#5, #5A, #6, #7, #8, #9, #9A, #9B, #10, #11, #12, #13, #14
- To: Fahlman@C.CS.CMU.EDU
- Subject: #5, #5A, #6, #7, #8, #9, #9A, #9B, #10, #11, #12, #13, #14
- From: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
- Date: Wed, 30 Jul 86 01:32 EDT
- Cc: Common-Lisp@SU-AI.ARPA
- In-reply-to: <FAHLMAN.12224580594.BABYL@C.CS.CMU.EDU>
- References: <FAHLMAN.12226116535.BABYL@C.CS.CMU.EDU>, <12226310687.19.LOOSEMORE@UTAH-20.ARPA>, The message of 25 Jul 86 00:30-EDT from Dave.Touretzky@A.CS.CMU.EDU, <860728202419.3.MOON@EUPHRATES.SCRC.Symbolics.COM>, <860728205756.7.MOON@EUPHRATES.SCRC.Symbolics.COM>, <860728212151.9.MOON@EUPHRATES.SCRC.Symbolics.COM>, <RAM.12224974495.BABYL@C.CS.CMU.EDU>
Proposals #5, #5A: PARSE-BODY
I think it's important to standardize on PARSE-BODY in some
form, distinct from &BODY. Most people probably wouldn't need
it, but those who did need it should -not- be encouraged to
write their own.
Don't call the argument DOCUMENTATION-ALLOWED-P. The issue
isn't whether a doc string is accepted, it's whether a string
in that position should be assumed to be a doc string or
assumed to be a literal constant. (DEFUN FOO (X) "hi" X)
would be a valid program even if there were no such thing
as a doc string. Call the arg PARSE-DOCUMENTATION-P.
The additional return values suggested in proposal 5A seem
misguided to me. I prefer returning just body, declares,
and doc in that order.
I think the BODY should be a list of forms with the first
form potentially macroexpanded since the pre-expanded form
is easy to recover by doing something like:
(CAR (LAST (LDIFF unparsed-body (CDR parsed-body))))
Actually, though, the macro might have smashed the macro
call's argument list, perhaps not even leaving it in a
semantically meaningful form, though more commonly just
displacing the macro expansion in place. So claiming you
were going to return an unexpanded form would be impossible
to really do in the general case.
Related questions: Is there anything in CLtL that specifies
that the "foo" in (LAMBDA FOO () "foo") has a body form of
"foo" and not just a doc string of "foo" with a null body list?
Is there anything that says whether
(LAMBDA (X) "foo" (DECLARE (IGNORE X)))
is well-formed or what it returns? Regardless of the answers
to these questions, having PARSE-BODY around would mean that
individual users would not have to develop private heuristic
When everyone's done with this initial round of comments,
I'd want to see a reworked proposal so that I could give
a boolean vote.
Proposal #6: Parsing in &BODY
I strongly lean toward the syntax I proposed. In addition to
the issues of upward-compatibility with existing code and the
argument about symmetry with &REST, it just involves less parens.
Also, I'm inclined to agree with Sandra that &REST and &BODY
need not be mutually exclusive. This would be properly consistent
with the conjoined use of &REST and &KEY, and with the conjoined
use of &WHOLE and other arguments.
Proposal #7: TYPE-SPECIFIER-P
I agree with Moon that this should only be called TYPE-SPECIFIER-P
if it were going to really predicate type expressions and not type
symbols. I'm content to include only TYPE-NAME-P for now. The need
for this comes up in my error proposal implementation in a situation
where SYMBOLP ends up sufficing (modulo reduced error checking). I
think TYPE-NAME-P is an important primitive to have.
Proposal #8: Clarifications to DEFCONSTANT
I concur with most of Moon's remarks here. Also, I think it's pretty
clear that EQUAL is an acceptable predicate since even in the case of
(DEFCONSTANT FOO (LIST 'A 'B))
where the person is obviously going to work to get something less
(DEFCONSTANT FOO '(A B))
would have gotten him, the compiler is under no contract to preserve
that absence of sharing in the inlined code it outputs to binary files.
Perhaps we should say explicitly that it is an error to side-effect
a system constant, and permit systems to warn in compiled code about
things like (SETF (CAR FOO) 3), to signal an error at runtime (eg, by
putting such constants in read-only areas), etc.
I would prefer that the warning about redefining a constant be
refined to make the "is an error" part dependent on whether the programs
have made assumptions about the value of the constant, not just whether
they refer to the constant. eg, macros might have called functions which
use the old value even if they do not themselves refer to the constant
I would also prefer that the warning about redefining constants refer
not only to compiled code being invalidated but also to interpreted code.
If particular implementations happen to not make assumptions about
constants in interpreted code, that's ok but should not be part of any
guarantee offered by CL. That way, implementations are not precluded from
doing prelimary Scheme-style semantic analysis even in interpreted code.
Proposal #9, #9A, #9B: Variable Name Conflicts
My feeling is that &AUX and LET* should not be subject to the variable
name conflict rule. I agree with completely with Dave Touretzky's comment
that "outlawing duplicate names in LET* promotes too shallow a notion of
consistency: one based on syntax rather than semantics."
The case of DO* is interesting. Although superficially this seems similar
to DO in the same way as LET* is to LET, I think at a deeper level it is
not quite as analagous. Could someone please explain to me what a repeated
variable would mean? Would the second one be a side-effect at the same
level or would it actually shadow something? If shadowed, is the shadowing
magically undone when you get to stepping the variable or do both steps
refer to the value of the second variable in the init column? Unless
someone can suggest a meaning for repeated variables in this context, I'd
suggest that repeated var names in DO* be made illegal even if it's allowed
in &AUX and LET*.
In my mind, there's no real basis for Masinter's claim that the
declaration issue needs to get involved here. If you have
(DEFUN FOO (X &AUX (X (F X)) (X (G X))) (DECLARE (SPECIAL X)) (H X))
and you're wondering which of F, G, and H will see the special X, I
think we should say arbitrarily -- only H. People should break up the &AUX
into nested LET expressions with explicit declarations as appropriate if
they want otherwise. Ditto for LET*.
I cannot agree to any of #9, #9A, or #9B.
Proposal #10: Forms That Allow Declarations
I'd like to see declarations allowed in a LABELS or FLET.
I agree with those who've suggested that this would not be appropriate for
MACROLET. Unlike FLET, LABELS, LET, etc. which introduce semantic terms,
MACROLET introduces only syntactic terms. If DECLARE was ever needed
inside a MACROLET, it is probably just a coincidence and not a result
of the MACROLET.
Proposal #11: Contents of Tagbody
I hate arbitrary little rules that say things like only symbols and
integers are allowed. The reason we can get away with tags at all
is that they're atoms and atoms can't have side-effects. I think all
atoms should be allowed here. I think we should just define the
predicate that gets used, and I think the predicate should be EQL.
Maybe someone will come up with a creative use of character objects
as tags. I see no reason to preclude that.
I note that in your proposal 12, you say "... the same (EQL) tag ...",
and I put that forth as evidence that this is how people already like
to think about tag equivalence.
Proposal #12: Unique Names For Tags
This seems non-controversial.
Proposal #13: Structure Sharing in Arguments
In the case of &REST in macros, I see no reason to not simply say
that the argument list is -always- shared. Is there an argument for
why this might not always be possible? In the case of &BODY, it may
not be possible to do the sharing, so I'm willing to leave this
undefined and say it "is an error" to modify the list.
For a function that takes &REST arguments, I would prefer that a copy
always be made unless the interpreter or compiler can prove that it
won't be necessary. If we cannot agree to do that, then it must be
noted both that it "is an error" to modify such a list AND that it
is an error to pass such a list to someone else using APPLY and then
later modify it. eg, (PROGN (APPLY #'FOO L) (SETF (CDR L) ...))
may screw up state that FOO has encached for later use.
Proposal #14: THE and VALUES
I'm not happy with this form of the clarification.
I agree with Moon that the discussion of &keywords in the VALUES
declaration seems pretty out of place. We don't check number of return
values or do &keyword-hacking on return values anywhere else so
doing it here seems out of place.
If we did keep it, though, I'd want (THE type form) to be equivalent
to (THE (VALUES type &REST T) form) and would want any use of
(VALUES ...) to mean that I expected exactly the indicated number
Others seem to be disagreeing, though, so it may be better to agree
to think harder on the issue and for now not bother to try gratuitously
"clarifying" something we don't adequately understand.