#5, #5A, #6, #7, #8, #9, #9A, #9B, #10, #11, #12, #13, #14

[Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>]

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 
 solutions.

 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
 EQL than
 (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
 explicitly.

 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
 of values.

 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.