Issue Status -- Summary of KMP's positions

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

Sorry for the delay in all this. For those who are watching their mailboxes
up until they step onto the plane, here is my complete list of endorsements
on the issues which Masinter has labeled as candidates to go before X3J13.
In the case of all "No" votes, comments follow at the end detailing the
reason for my position.

Yes  - Proposal format (Version 12, 23-Oct-87)
Yes  - AREF-1D (Version 6, 6 JUL 87)
Yes  - COLON-NUMBER (Version 1, 22-oct-87)
Yes  - DECLARE-MACROS (Version 2,  9-Nov-87)
Yes  - DEFVAR-DOCUMENTATION (Version 1, 30-Jun-87)
Yes  - FORMAT-COMMA-INTERVAL (Version 2, 15 June 87)
No   - FUNCTION-TYPE (Version 7, 9-Nov-87)
Yes  - GET-SETF-METHOD-ENVIRONMENT (Version 5, 13-Jun-87)
Yes  - KEYWORD-ARGUMENT-NAME-PACKAGE (Version 8, 8-Nov-87)
No   - LOAD-TIME-EVAL (Version 2, 17-JUL-87)
No   - PATHNAME-STREAM (Version 5, 23-Oct-87)
No   - PUSH-EVALUATION-ORDER (Version 3, 8-Nov-87)
Yes  - SETF-METHOD-FOR-SYMBOL (Version 3, 11-Nov-87)
No   - SETF-FUNCTION-VS-MACRO (Version 3, 4-Nov-87)
No   - SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 4, 11-Nov-87)
Yes  - SHADOW-ALREADY-PRESENT (Version 4, 10-Nov-87 23:59:43)
Yes  - SHARPSIGN-PLUS-MINUS-PACKAGE (version 2, 10-Nov-87)
No   - TRACE-FUNCTION-ONLY (Version 5, 9-Nov-87)

FUNCTION-TYPE (version 7)
 I strongly object to the coupling of the FUNCTION type cleanup and the
 implicit coercion. The former I support in principle and the latter I
 am very unsure about. To clarify my views, I have distributed an
 alternate proposal FUNCTION-TYPE:CONSERVATIVE as version 8 of this
 proposal.

PATHNAME-STREAM (version 5)
 I generally approve, but agree with Moon's concerns that the restrictions
 on synonym streams are really gratuitous. Since this isn't a high priority
 item, it can easily be deferred until the next meeting while we get this
 worked out (if we can't work it out in person on Monday).

PUSH-EVALUATION-ORDER (version 3)
 I'd be in favor of something cleaning up this wording, but the issues
 which Masinter had raised had been nagging at me, too. I'd like to see
 Moon draft a proposal that addresses these issues explicitly.

SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (version 4)
 I can't support the GENERALIZE proposal; I want to return to the
 MODIFIED proposal.  My reasons are not those described in the summary as
 the "majority reason for opposition." Rather, I am worried about the
 fact that, as Touretzky himself pointed out, this proposal is aimed at
 de-emphasizing the importance of the container shape. I think the 
 Lisp language has traditionally placed great importance on structural
 shape and I am not happy to toss all that aside. I am happy to define
 COERCE to allow coercion of matrices to vectors because that allows the
 programmer to express explicit intent. I am also happy to allow implicit
 coercion on operations that abstractly make sense without having to think
 about shape changing. For now, though, that's as far as I'm willing to go.

SETF-FUNCTION-VS-MACRO (version 3)
 I recognize this as an important concern and generally approve of making
 a proposal along these lines, but there are a lot of particulars that I
 am not sure about. If this goes to a vote now, it should mark me as
 believing that it is premature. Among the issues I'd like more time to
 think about are the choice of SETF as the symbol in the car of the name
 list, the ability to supply a non-symbol to SYMBOL-FUNCTION, the syntax
 implications for TRACE (since some implementations already define a
 meaning for lists occurring in TRACE's argument positions).

TRACE-FUNCTION-ONLY (version 5)
 Probably something along these lines is appropriate, but I would like
 to see this tabled pending action on the SETF-FUNCTION-VS-MACRO issue
 and on the CLOS spec. Further, I think it would be better to do a more
 general review of what functionality TRACE might want to provide.
 We risk getting ourselves in a situation where (TRACE ... list ...)
 is overloaded in such a way that (TRACE (METHOD ...)) might mean either
 to trace a function called METHOD or to trace a method. Although this
 could be resolved using heuristics, it would be bad for us to muck
 up the syntax so badly that we had to resort to heuristics to dig
 ourselves out.