[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: firstname.lastname@example.org
- Subject: ballot
- From: email@example.com (Gail Zacharias)
- Date: 9 Jan 89 22:54:47 EST (Mon)
This ballot is the official position of Apple Computer.
"Yes if" means we won't vote for the proposal unless a condition is satisfied.
"Yes" with a comment means we'd like to see a change, but will vote for it
Version 4, 21-Sep-88, Mailed 4 Dec 88
Yes if ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING
Version 9, 31-Oct-88, Mailed 5 Dec 88
Flush the UPGRADED-xxx functions.
Version 5, 5-Dec-88, Mailed 5 Dec 88
Would prefer to specify a value for CLOSE on closed streams. What's the
point of leaving it undefined?
Version 1, 14-Sep-88, Mailed 6 Oct 88
Version 8, 7-Dec-88, Mailed 9-Dec-88
We'll probably support the LEXICAL option (not on the ballot).
Version 4, 15-Nov-88, Mailed 9-Dec-88
Version 4, 5-Dec-88, Mailed 5-Dec-88
Version 2, 30-Sep-88, Mailed 6 Oct 88
Version 7, 2-Nov-88, Mailed 5 Dec 88
Yes if DEFSTRUCT-SLOTS-CONSTRAINTS-NAME:DUPLICATES-ERROR
Version 4, 31-Oct-88, Mailed 12-Dec-88
The proposal should state that the constraint applies only to the
arguments to the DEFSTRUCT macro. It does not constrain the STRUCTURE-CLASS
metaclass to require all slots to have STRING/= names.
Version 2, 21-Sep-88, Mailed 6 Oct 88
Needs to specify whether the keyword or variable name is the slot name.
Version 3, 7 Dec 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
Version 5, 12-Dec-88, Mailed 12-Dec-88
Version 3, 31-Oct-88, Mailed 7 Dec 88
Yes if FIXNUM-NON-PORTABLE:TIGHTEN-DEFINITION
Version 4, 7-Dec-88, Mailed 12-Dec-88
We'll support TIGHTEN-DEFINITION iff TIGHTEN-FIXNUM-TOSS-BIGNUM fails.
Version 2, 2 Oct 88, Mailed 6 Oct 88
Version 7, 15 Dec 88, Mailed 7 Dec 88
Yes if FUNCTION-COMPOSITION:COMPLEMENT-AND-ALWAYS
Version 4, 12 Dec 88, Mailed 12 Dec 88
If ALWAYS is renamed to CONSTANT or CONSTANTLY.
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 7, 8-Dec-88, Mailed 9-Dec-88
Should be functions.
Version 1, 11-Nov-88 , Mailed 12 Dec 88
As best we can tell, all this proposal says is that it is an error to
destructively modify elements of equal hash tables but ok to do so for eq
hash tables. We would support a simpler proposal stating this.
Version 2, 8-Dec-88, Mailed 8 Dec 88
Version 4, 12-Dec-88, Mailed 12-Dec-88
Version 4, 22-Nov-88, Mailed 8-Dec-88
New special form would be even better.
Version 1, 17 Oct 88, Mailed 8 Dec 88
Version 2, 8 Dec 88, Mailed 8 Dec 88
Version 5, 22-Nov-88, Mailed 8 Dec 88
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
Clarify that NIL should be returned when index is larger than number of values
Version 6, 12-Dec-88, Mailed 12-Dec-881
Yes if PACKAGE-DELETION:NEW-FUNCTION
Version 5, 21 nov 88, Mailed 8 Dec 88
Remove the description of "correctable" error to be signalled and handled.
This sort of detailed error protocol is not specified for any other function
and is not appropriate here.
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
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
NIL should be allowed for start, allowing it for some arguments (count,
end) and not others (start) is too obscure.
Version 6, 9 Dec 88, mailed 09 Dec 88
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]
Version 3, 4-Nov-87, mailed Nov 87
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
Yes if STREAM-ACCESS:ADD-TYPES-ACCESSORS
version 2, 30-Nov-88 mailed 9 Dec 88
(expect amendment T => "true")
The following paragraph from the description of OPEN-STREAM-P may
Streams are "open" until they have been closed with CLOSE, or, the
dynamic context of the creating/accessing macros of WITH-OUTPUT-TO-STRING,
WITH-OPEN-FILE, WITH-INPUT-FROM-STRING, WITH-OPEN-STREAM, have been
This may be taken to imply that the stream still exists (as a closed stream)
even after the dynamic extent of the WITH-xxx form is exited. Because these
stream objects have dynamic extent, they cannot be referenced in any way once
the WITH-xxx form exits. (They can't even be passed to OPEN-STREAM-P.) As a
practical example, the streams could be stack-consed, and future use could
cause crashes. The reference to exited WITH-xxx forms should be deleted, or
explanatory text should be added.
Version 6, 30-Nov-88, mailed 9 dec 88
LINE-WIDTH ==> STREAM-LINE-WIDTH
LINE-POSITION ==> STREAM-LINE-POSITION
PRINTED-WIDTH ==> STREAM-STRING-WIDTH
Our opposition is based on the following points:
1) The defining property of WRITE-SPACE (that it must write exactly the number
of units given) is too restrictive. For example it may not be possible to
write whitespace to a stream in units smaller than a #\space character, if the
stream is associated with a (multi-font) ascii file or editor buffer (since
there may be no ascii character available that can be inserted in the
file/buffer to represent the whitespace). An implementation cannot simply
make the unit size equal to the width of a #\space character, because a
subsequent increase in font-size would again make the unit smaller than a
current #\space character.
2) The "additional properties" of PRINTED-WIDTH (i.e. 8 and 9, stating that
printed-widths are additive) are incompatible with some non-Roman scripts. For
example, in the Arabic language the glyphs used for characters are dependent
on the surrounding characters: in our Arabic implementation of Object Logo,
editing causes surrounding characters to change shape (and width) according to
their new context. The restrictions on PRINTED-WIDTH would make it difficult
to similarly incorporate the context-sensitive character portrayal features of
the Macintosh into our Common Lisp implementation.
3) In general we feel that the proposal is premature, given the current state
of i/o standards. We would prefer to wait for a complete solution (i.e. a
real graphics standard and extended characters set standard). We feel that
the current proposal is too specific and problematical for a proper place in
Common Lisp. For now, the desired features are probably best obtained via
Version 4, 7-Oct-88, mailed 7 Oct 88
Version 2, 9-Dec-88, mailed 9 Dec 88
Version 5, 30-Nov-88, mailed 9 Dec 88
Yes if TAGBODY-CONTENTS:FORBID-EXTENSION
Version 5, 9-Dec-88 mailed 9 Dec 88
We support forbidding extensions, but oppose allowing duplicate and
unreachable tags. Instead we would prefer clarifying that () is a form
and not a valid tag.
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
Version 3, 08-Oct-88, mailed 9 Dec 88