[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[email@example.com (Aaron Larson): Ballots, please]
- To: firstname.lastname@example.org
- Subject: [email@example.com (Aaron Larson): Ballots, please]
- From: masinter.pa@Xerox.COM
- Date: 7 Jan 89 21:04 PST
----- Begin Forwarded Messages -----
Received: from moon.src.honeywell.com ([220.127.116.11]) by Xerox.COM ; 07 JAN
89 19:26:09 PST
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: firstname.lastname@example.org (Aaron Larson)
In-Reply-To: masinter.pa@Xerox.COM's message of 6 Jan 89 00:23 PST
Subject: Ballots, please
This bounced the first time so...
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
Version 4, 21-Sep-88, Mailed 4 Dec 88
Version 9, 31-Oct-88, Mailed 5 Dec 88
Version 5, 5-Dec-88, Mailed 5 Dec 88
Version 1, 14-Sep-88, Mailed 6 Oct 88
no-hoisting, but if there was serious objection, would accept this one
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
Version 8, 7-Dec-88, Mailed 9-Dec-88
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
Version 2, 21-Sep-88, Mailed 6 Oct 88
Version 3, 7 Dec 88, Mailed 12-Dec-88
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
Version 4, 15-Nov-88 , Mailed 7-Dec-88
Version 3, 15-Nov-88, Mailed 7-Dec-88
Version 5, 1-Oct-88, Mailed 8 Oct 88
semantics are bad.
Version 5, 12-Dec-88, Mailed 12-Dec-88
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.
Version 2, 2 Oct 88, Mailed 6 Oct 88
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".
Version 4, 12 Dec 88, Mailed 12 Dec 88
Version 2, 09-Dec-88 , Mailed 9 Dec 88
Version 3, 7-Dec-88, Mailed 12-Dec-88
Version 5, 14-Nov-88 , Mailed 8-Dec-88
Version 2, 8 Dec 88, Mailed 8 Dec 88
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
Version 2, 8-Dec-88, Mailed 8 Dec 88
conditionally on defpackage passing.
Version 4, 12-Dec-88, Mailed 12-Dec-88
Version 4, 22-Nov-88, Mailed 8-Dec-88
Version 1, 17 Oct 88, Mailed 8 Dec 88
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
Version 2, 09-Jun-88, Mailed 8 Oct 88
Version 4, 8-Dec-88, Mailed 8 Dec 88
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
Version 1 27-Jun-88, Mailed 7 Oct 88
Version 3, 8-Oct-88, Mailed 8 Oct 88
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
Version 3, 9-Oct-88, Mailed 14-Oct-88
Version 1, 14-Sep-88, Mailed 7 Oct 88
Version 6, 9 Dec 88, mailed 09 Dec 88
REST-LIST-ALLOCATION:MAY-SHARE All three
stink. No idea what to do.
Version 3, 12-Dec-88, mailed 12-Dec-88
Version 6, 9 Dec 88 mailed 9-Dec-88
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
Version 5, 12-Feb-88 mailed 8 Oct 88
Version 8, 8 Jul 88, Mailed 7 Oct 88
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
LINE-WIDTH ==> STREAM-LINE-WIDTH
LINE-POSITION ==> STREAM-LINE-POSITION
PRINTED-WIDTH ==> STREAM-STRING-WIDTH
Version 4, 7-Oct-88, mailed 7 Oct 88
SYMBOL-MACROLET-DECLARE:ALLOW Yes (check
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
Version 5, 9-Dec-88 mailed 9 Dec 88
Version 5, 9-Dec-88, mailed 12-Dec-88
Version 3, 1 Dec 88 mailed 9 dec
Version 3, 12-Dec-88, mailed 12 Dec 88
(some "bugs" in the proposal)
Version 2, 2-Dec-88, mailed 12-Dec-88
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 -----