[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[alarson@src.honeywell.com (Aaron Larson): Ballots, please]
- To: cl-cleanup@sail.stanford.edu
- Subject: [alarson@src.honeywell.com (Aaron Larson): Ballots, please]
- From: masinter.pa@Xerox.COM
- Date: 7 Jan 89 21:04 PST
----- Begin Forwarded Messages -----
Return-Path: <alarson@src.honeywell.com>
Received: from moon.src.honeywell.com ([129.30.1.10]) by Xerox.COM ; 07 JAN
89 19:26:09 PST
Return-Path: <alarson@src.honeywell.com>
Received: from pavo.SRC.Honeywell.COM
by moon.src.honeywell.com (5.59/smail2.6.3/06-17-88)
id AA17213; Sat, 7 Jan 89 21:25:49 CST
Posted-Date: Sat, 7 Jan 89 21:24:16 CST
Received: by pavo.src.honeywell.com (3.2/SMI-3.2)
id AA13383; Sat, 7 Jan 89 21:24:16 CST
Date: Sat, 7 Jan 89 21:24:16 CST
From: alarson@src.honeywell.com (Aaron Larson)
Message-Id: <8901080324.AA13383@pavo.src.honeywell.com>
To: masinter.pa
In-Reply-To: masinter.pa@Xerox.COM's message of 6 Jan 89 00:23 PST
<890106-002339-193@Xerox>
Subject: Ballots, please
This bounced the first time so...
To: masinter.pa@xerox.COM
Subject: Re: ** BALLOT ** BALLOT ** BALLOT ** BALLOT **
The following is my ballot. There are a couple of baked comments, mostly
notes to myself that I've not had time to check out throughly. If they are
not clear or usefull, simply ignore them. All my comments appear on a
single line at the side of the issue name, if this is a mess on your
system, let me know and I'll reformat. Also, note that I did not copy
cl-cleanup.
!
ARGUMENTS-UNDERSPECIFIED:SPECIFY Yes.
Version 4, 21-Sep-88, Mailed 4 Dec 88
ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING Yes.
Version 9, 31-Oct-88, Mailed 5 Dec 88
CLOSED-STREAM-OPERATIONS:ALLOW-INQUIRY Yes
Version 5, 5-Dec-88, Mailed 5 Dec 88
CONTAGION-ON-NUMERICAL-COMPARISONS:TRANSITIVE Yes
Version 1, 14-Sep-88, Mailed 6 Oct 88
DECLARATION-SCOPE:NO-HOISTING Yes.
DECLARATION-SCOPE:LIMITED-HOISTING Prefer
no-hoisting, but if there was serious objection, would accept this one
also.
Version 4, 15-Nov-88, Mailed 9-Dec-88
DECLARE-FUNCTION-AMBIGUITY:DELETE-FTYPE-ABBREVIATION Yes. (I
thought this already passed?)
Version 4, 5-Dec-88, Mailed 5-Dec-88
DECLARE-TYPE-FREE:ALLOW Yes.
Version 8, 7-Dec-88, Mailed 9-Dec-88
DECODE-UNIVERSAL-TIME-DAYLIGHT:LIKE-ENCODE Abstain
Version 2, 30-Sep-88, Mailed 6 Oct 88
DEFPACKAGE:ADDITION Yes. I
believe that "should signal an error" should be "will signal an error".
Version 7, 2-Nov-88, Mailed 5 Dec 88
DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE:ALLOW-KEY Yes
Version 2, 21-Sep-88, Mailed 6 Oct 88
DEFSTRUCT-PRINT-FUNCTION-INHERITANCE:YES Yes
Version 3, 7 Dec 88, Mailed 12-Dec-88
DEFSTRUCT-SLOTS-CONSTRAINTS-NAME:DUPLICATES-ERROR Confused,
why string= on the names. Does that mean that foo:a and bar:a cannot both
be slots in the same structure? (check where accessors are interned).
Version 4, 31-Oct-88, Mailed 12-Dec-88
DESCRIBE-INTERACTIVE:EXPLICITLY-VAGUE Abstain
DESCRIBE-INTERACTIVE:NO Yes
Version 4, 15-Nov-88 , Mailed 7-Dec-88
DOTTED-MACRO-FORMS:ALLOW Yes
Version 3, 15-Nov-88, Mailed 7-Dec-88
EQUAL-STRUCTURE:STATUS-QUO Yes
Version 5, 1-Oct-88, Mailed 8 Oct 88
EXIT-EXTENT:MINIMAL No,
semantics are bad.
EXIT-EXTENT:MEDIUM Yes
Version 5, 12-Dec-88, Mailed 12-Dec-88
EXPT-RATIO:P.211 Yes
Version 3, 31-Oct-88, Mailed 7 Dec 88
FIXNUM-NON-PORTABLE:TIGHTEN-DEFINITION No. fixnum
is defined to be non portable, if portable code needs to be written, then
(integer low up) is the way to specify it.
FIXNUM-NON-PORTABLE:TIGHTEN-FIXNUM-TOSS-BIGNUM I agree
bignum is not usefull, but there are other non usefull aspects of the
language, and changing them now requires better justification.
Version 4, 7-Dec-88, Mailed 12-Dec-88 I don't
feel strongly about either of the above statements.
FORMAT-E-EXPONENT-SIGN:FORCE-SIGN Yes
Version 2, 2 Oct 88, Mailed 6 Oct 88
FORMAT-PRETTY-PRINT:YES Yes
Version 7, 15 Dec 88, Mailed 7 Dec 88
FUNCTION-COMPOSITION:NEW-FUNCTIONS No. Also,
there is an error in the proposal, the example for find-if specifies AND
and DISJOIN to be equivalent. Not very "perspicuous".
FUNCTION-COMPOSITION:COMPLEMENT-AND-ALWAYS No
Version 4, 12 Dec 88, Mailed 12 Dec 88
FUNCTION-DEFINITION:FUNCTION-SOURCE Abstain
Version 2, 09-Dec-88 , Mailed 9 Dec 88
FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS:RESTRICTIVE Yes.
Version 3, 7-Dec-88, Mailed 12-Dec-88
FUNCTION-TYPE-REST-LIST-ELEMENT:USE-ACTUAL-ARGUMENT-TYPE No/Abstain
Version 5, 14-Nov-88 , Mailed 8-Dec-88
GET-MACRO-CHARACTER-READTABLE:NIL-STANDARD Yes
Version 2, 8 Dec 88, Mailed 8 Dec 88
HASH-TABLE-PACKAGE-GENERATORS:ADD-WITH-WRAPPER Abstain
Version 7, 8-Dec-88, Mailed 9-Dec-88
HASH-TABLE-STABILITY:KEY-TRANSFORM-RESTRICTIONS ??, very
long. Check SXHASH, I thought it was supposed to work accross different
invocations of lisp. This appears to not be the case according to the
proposal. Since the proposal really i
sn't changing the language (I hope), then it is really only a clarification
of existing status, but I'm not sure I understand the issue any more now
than before I read it.
Version 1, 11-Nov-88 , Mailed 12 Dec 88
HASH-TABLE-TESTS:ADD-EQUALP Yes
Version 2, 8-Dec-88, Mailed 8 Dec 88
IN-PACKAGE-FUNCTIONALITY:SELECT-ONLY Yes,
conditionally on defpackage passing.
Version 4, 12-Dec-88, Mailed 12-Dec-88
LAMBDA-FORM:NEW-MACRO Abstain
Version 4, 22-Nov-88, Mailed 8-Dec-88
LCM-NO-ARGUMENTS:1 Yes
Version 1, 17 Oct 88, Mailed 8 Dec 88
LISP-SYMBOL-REDEFINITION:DISALLOW Yes
Version 5, 22-Nov-88, Mailed 8 Dec 88
MAKE-PACKAGE-USE-DEFAULT:IMPLEMENTATION-DEPENDENT yea sure.
People writing portable code have more subtle problems to worry about than
the default :USE list anyhow.
Version 2, 8 Oct 88, Mailed 12-Dec-88
MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE Yes
Version 2, 09-Jun-88, Mailed 8 Oct 88
NTH-VALUE:ADD Abstain/No
Version 4, 8-Dec-88, Mailed 8 Dec 88
PACKAGE-CLUTTER:REDUCE yes.
Version 6, 12-Dec-88, Mailed 12-Dec-881
PACKAGE-DELETION:NEW-FUNCTION YES, (minor
editorial comment sent to cleanup (sorry bout that).
Version 5, 21 nov 88, Mailed 8 Dec 88
PATHNAME-TYPE-UNSPECIFIC:NEW-TOKEN Yes
Version 1 27-Jun-88, Mailed 7 Oct 88
PEEK-CHAR-READ-CHAR-ECHO:FIRST-READ-CHAR Yes
Version 3, 8-Oct-88, Mailed 8 Oct 88
PRINT-CIRCLE-STRUCTURE:USER-FUNCTIONS-WORK Yes
Version 3, 20 Sep 88, Mailed 8 Oct 88
PROCLAIM-LEXICAL:LG If it can
be implemented easily then I'm for it. (I thought symbol-value got the
global value, not the dynamic one??)
Version 9, 8-Dec-88, Mailed 12-Dec-88
RANGE-OF-COUNT-KEYWORD:NIL-OR-INTEGER Yes
Version 3, 9-Oct-88, Mailed 14-Oct-88
RANGE-OF-START-AND-END-PARAMETERS:INTEGER-AND-INTEGER-NIL Yes
Version 1, 14-Sep-88, Mailed 7 Oct 88
REQUIRE-PATHNAME-DEFAULTS:ELIMINATE Yes.
Version 6, 9 Dec 88, mailed 09 Dec 88
REST-LIST-ALLOCATION:NEWLY-ALLOCATED
REST-LIST-ALLOCATION:MAY-SHARE All three
stink. No idea what to do.
REST-LIST-ALLOCATION:MUST-SHARE
Version 3, 12-Dec-88, mailed 12-Dec-88
RETURN-VALUES-UNSPECIFIED:SPECIFY Yes
Version 6, 9 Dec 88 mailed 9-Dec-88
ROOM-DEFAULT-ARGUMENT:NEW-VALUE Abstain
Version 1 12-Sep-88 mailed 8 Oct 88
[The following are mutually exclusive]
SETF-FUNCTION-VS-MACRO:SETF-FUNCTIONS Much better
than before. Inroducing (setf name) as names for functions is still ugly.
Questions such as what about macros?? Generalized function specs? etc. I
would vote for it if nothing
better comes along.
Version 3, 4-Nov-87, mailed Nov 87
SETF-PLACES:ADD-SETF-FUNCTIONS No, it
would require most code to have things like (flet
((#.(underlying-spec-to-name ..))) (defsetf...)) which is very gross. It
would also be a very big portability issue, because implemen
tations with function specs would probably work without the defsetf, which
is fairly subtle.
Version 1, 11-Nov-88, mailed 9-Dec-88
SETF-SUB-METHODS:DELAYED-ACCESS-STORES Yes
Version 5, 12-Feb-88 mailed 8 Oct 88
STANDARD-INPUT-INITIAL-BINDING:DEFINED-CONTRACTS Yes
Version 8, 8 Jul 88, Mailed 7 Oct 88
STEP-ENVIRONMENT:CURRENT Yes
Version 3, 20-Jun-88, mailed 7 Oct 88
STREAM-ACCESS:ADD-TYPES-PREDICATES-ACCESSORS Yes, order
of perferense stream-access:add-types-accessors, then
add-types-predicates-accessors, I'm not fond of add-predicates-accessors,
but not stronly opposed.
version 2, 30-Nov-88 mailed 9 Dec 88
(expect amendment T => "true")
STREAM-INFO:ONE-DIMENSIONAL-FUNCTIONS Yes, Prefer
ammendment. Also, I believe that the specification of the "basic
properties" makes no mention of the fact that NIL can be returned by any of
the functions. This somewhat implies
that they are required to return non nil values, although I believe the
proposal permits them too.
Version 6, 30-Nov-88, mailed 9 dec 88
expect amendment:
LINE-WIDTH ==> STREAM-LINE-WIDTH
LINE-POSITION ==> STREAM-LINE-POSITION
PRINTED-WIDTH ==> STREAM-STRING-WIDTH
SUBTYPEP-TOO-VAGUE:CLARIFY Yes
Version 4, 7-Oct-88, mailed 7 Oct 88
SYMBOL-MACROLET-DECLARE:ALLOW Yes (check
-SEMANTICS)
Version 2, 9-Dec-88, mailed 9 Dec 88
SYMBOL-MACROLET-SEMANTICS:SPECIAL-FORM Yes (need
to think about it more, complex issue)
Version 5, 30-Nov-88, mailed 9 Dec 88
TAGBODY-CONTENTS:FORBID-EXTENSION Yes
Version 5, 9-Dec-88 mailed 9 Dec 88
TAILP-NIL:T Yes
Version 5, 9-Dec-88, mailed 12-Dec-88
TEST-NOT-IF-NOT:FLUSH-ALL No/Abstain
TEST-NOT-IF-NOT:FLUSH-TEST-NOT
Version 3, 1 Dec 88 mailed 9 dec
TYPE-OF-UNDERCONSTRAINED:ADD-CONSTRAINTS Yes
Version 3, 12-Dec-88, mailed 12 Dec 88
(some "bugs" in the proposal)
UNREAD-CHAR-AFTER-PEEK-CHAR:DONT-ALLOW Yes
Version 2, 2-Dec-88, mailed 12-Dec-88
VARIABLE-LIST-ASYMMETRY:SYMMETRIZE No/Abstain.
Error checking gained by disallowing (var) is more important to me than
symmetry. If anything (var) should be disallowed in all forms.
Version 3, 08-Oct-88, mailed 9 Dec 88
----- End Forwarded Messages -----