[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Symbolics response to mail ballot
- To: CL-Cleanup@SAIL.Stanford.EDU
- Subject: Symbolics response to mail ballot
- From: Moon@STONY-BROOK.SCRC.Symbolics.COM, KMP@STONY-BROOK.SCRC.Symbolics.COM
- Date: Thu, 5 Jan 89 14:10 EST
- Sender: KMP@STONY-BROOK.SCRC.Symbolics.COM
These votes represent the official position of Symbolics.
Because of the volatility of some issues from version to version,
readers are reminded that our votes apply only to the indicated
versions of the writeup.
In the notes column, "comment" means we have comments which do
not necessarily affect our vote, but which we felt important
to mention. On the other hand, "provisional" means that
we have placed conditions on the indicated vote, and the vote does
not apply unless the conditions are met. Comments and provisions
follow at the end of this message.
Blank lines in the summary are just for readability. They don't
indicate any kind of grouping.
---Summary---
Issue:Proposal(Version) Vote Notes
ARGUMENTS-UNDERSPECIFIED:SPECIFY(4) Yes ---
ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING(9) Yes comment
CLOSED-STREAM-OPERATIONS:ALLOW-INQUIRY(5) Yes ---
CONTAGION-ON-NUMERICAL-COMPARISONS:TRANSITIVE(1) Yes ---
DECLARATION-SCOPE:LIMITED-HOISTING(4) Yes ---
DECLARATION-SCOPE:NO-HOISTING(4) No ---
DECLARE-FUNCTION-AMBIGUITY:DELETE-FTYPE-ABBREVIATION (4) Yes comment
DECLARE-TYPE-FREE:ALLOW(8) No comment
DECLARE-TYPE-FREE:LEXICAL(9, unreleased) Yes comment
DECODE-UNIVERSAL-TIME-DAYLIGHT:LIKE-ENCODE(2) Yes ---
DEFPACKAGE:ADDITION(7) Yes comment
DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE:ALLOW-KEY(2) Yes comment
DEFSTRUCT-PRINT-FUNCTION-INHERITANCE:YES(3) Yes ---
DEFSTRUCT-SLOTS-CONSTRAINTS-NAME:DUPLICATES-ERROR(4) Yes ---
DESCRIBE-INTERACTIVE:EXPLICITLY-VAGUE(4) Yes ---
DESCRIBE-INTERACTIVE:NO(4) No comment
DOTTED-MACRO-FORMS:ALLOW(3) Yes ---
EQUAL-STRUCTURE:STATUS-QUO(5) No comment
EXIT-EXTENT:MINIMAL(5) No comment
EXIT-EXTENT:MEDIUM(5) No comment
EXPT-RATIO:P.211(3) Yes ---
FIXNUM-NON-PORTABLE:TIGHTEN-DEFINITION(4) Yes ---
FIXNUM-NON-PORTABLE:TIGHTEN-FIXNUM-TOSS-BIGNUM(4) No ---
FORMAT-E-EXPONENT-SIGN:FORCE-SIGN(2) Yes ---
FORMAT-PRETTY-PRINT:YES(7) Yes comment
FUNCTION-COMPOSITION:NEW-FUNCTIONS(4) Yes comment
FUNCTION-COMPOSITION:COMPLEMENT-AND-ALWAYS(4) No comment
FUNCTION-DEFINITION:FUNCTION-SOURCE(2) Yes ---
FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS:RESTRICTIVE(3) Yes ---
FUNCTION-TYPE-REST-LIST-ELEMENT:USE-ACTUAL-ARGUMENT-TYPE(5) Yes comment
GET-MACRO-CHARACTER-READTABLE:NIL-STANDARD(2) Yes comment
HASH-TABLE-PACKAGE-GENERATORS:ADD-WITH-WRAPPER(7) Yes comment
HASH-TABLE-STABILITY:KEY-TRANSFORM-RESTRICTIONS(1) No comment
HASH-TABLE-TESTS:ADD-EQUALP(2) Yes comment
IN-PACKAGE-FUNCTIONALITY:SELECT-ONLY(4) Yes provisional
LAMBDA-FORM:NEW-MACRO(4) Yes ---
LCM-NO-ARGUMENTS:1(1) Yes ---
LISP-SYMBOL-REDEFINITION:DISALLOW(5) Yes provisional
MAKE-PACKAGE-USE-DEFAULT:IMPLEMENTATION-DEPENDENT(2) No comment
MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE(2) Yes ---
NTH-VALUE:ADD(4) Yes comment
PACKAGE-CLUTTER:REDUCE(6) Yes comment
PACKAGE-DELETION:NEW-FUNCTION(5) Yes ---
PATHNAME-TYPE-UNSPECIFIC:NEW-TOKEN(1) Yes ---
PEEK-CHAR-READ-CHAR-ECHO:FIRST-READ-CHAR(3) Yes comment
PRINT-CIRCLE-STRUCTURE:USER-FUNCTIONS-WORK(3) Yes ---
PROCLAIM-LEXICAL:LG(9) Yes comment
RANGE-OF-COUNT-KEYWORD:NIL-OR-INTEGER(3) Yes ---
RANGE-OF-START-AND-END-PARAMETERS:INTEGER-AND-INTEGER-NIL(1) Yes ---
REQUIRE-PATHNAME-DEFAULTS:ELIMINATE(6) Yes ---
REST-LIST-ALLOCATION:MAY-SHARE(3) Yes ---
REST-LIST-ALLOCATION:NEWLY-ALLOCATED(3) No ---
REST-LIST-ALLOCATION:MUST-SHARE(3) No ---
RETURN-VALUES-UNSPECIFIED:SPECIFY(6) Yes ---
ROOM-DEFAULT-ARGUMENT:NEW-VALUE(1) Yes ---
SETF-FUNCTION-VS-MACRO:SETF-FUNCTIONS(3) No comment
SETF-PLACES:ADD-SETF-FUNCTIONS(1) No comment
SETF-SUB-METHODS:DELAYED-ACCESS-STORES(5) Yes ---
STANDARD-INPUT-INITIAL-BINDING:DEFINED-CONTRACTS(8) Yes ---
STEP-ENVIRONMENT:CURRENT(3) Yes provisional
STREAM-ACCESS:ADD-TYPES-ACCESSORS(2) Yes comment
STREAM-ACCESS:ADD-TYPES-PREDICATES-ACCESSORS(2) No comment
STREAM-ACCESS:ADD-PREDICATES-ACCESSORS(2) No comment
STREAM-INFO:ONE-DIMENSIONAL-FUNCTIONS Yes provisional
SUBTYPEP-TOO-VAGUE:CLARIFY(4) Yes comment
SYMBOL-MACROLET-DECLARE:ALLOW(2) Yes ---
SYMBOL-MACROLET-SEMANTICS:SPECIAL-FORM(5) Yes ---
TAGBODY-CONTENTS:FORBID-EXTENSION(5) Yes provisional
TAILP-NIL:T(5) Yes comment
TEST-NOT-IF-NOT:FLUSH-ALL(3) Yes provisional
TEST-NOT-IF-NOT:FLUSH-TEST-NOT(3) Yes provisional
TYPE-OF-UNDERCONSTRAINED:ADD-CONSTRAINTS(3) Yes provisional
UNREAD-CHAR-AFTER-PEEK-CHAR:DONT-ALLOW(2) Yes ---
VARIABLE-LIST-ASYMMETRY:SYMMETRIZE(3) Yes ---
---Detail---
Comment on ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 9, 31-Oct-88)
We don't think the functions UPGRADED-ARRAY-ELEMENT-TYPE and
UPGRADED-COMPLEX-PART-TYPE are really necessary, but neither of us
cares enough to pursue that issue. Otherwise it looks ok.
Comment on DECLARE-FUNCTION-AMBIGUITY (Version 4, 05-Dec-88)
Moon is mildly opposed to this proposal, DELETE-FTYPE-ABBREVIATION,
because he sees it as gratuitously incompatible. Pitman favors the
proposal because he thinks the benefit of making things regular will
outweigh the costs.
Comment on DECLARE-TYPE-FREE (Version 8, 07-Dec-88)
Moon approved of an earlier version of this proposal, and wrote
a new option, LEXICAL, as part of a version 9 which has not been
released to X3J13. Both Moon and Pitman support the LEXICAL proposal,
version 9.
Comment on DEFPACKAGE (Version 7, 02-Nov-88)
The semantics should be defined in terms of the existing package
functions rather than being redundantly described, in order to minimize
the risk that DEFPACKAGE and the package functions will accidentally
differ in some unintended way.
Comment on DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE (Version 2, 21-Sep-88)
The proposal should accomodate comments by IIM about some keywords
that were (presumably accidentally) not addressed
Comment on DESCRIBE-INTERACTIVE (Version 4, 15-Nov-88)
We prefer option EXPLICITLY-VAGUE.
We would vote "Yes" for the NO option iff EXPLICITLY-VAGUE fails.
Comment on EQUAL-STRUCTURE (Version 5, 01-Oct-88)
There are important technical comments about EQUALP which have not
been addressed, and which we feel must be addressed before this is
brought to a serious vote. Ultimately, when those pending technical
comments have been addressed, we expect to buy into this proposal.
Comment on EXIT-EXTENT (Version 5, 12-Dec-88)
Sadly, we feel it is still premature to vote on this issue at this time.
There are too many errors and inconsistencies in the writeup.
Comment on FORMAT-PRETTY-PRINT (Version 7, 15-Dec-88)
Although some fixes were made to accomodate ~R, some minor lingering
questions remain, which should be addressed under separate cover:
- Is PRINT-OBJECT used to print things of type FLOAT in any cases
where ~$, ~E, ~F, or ~G is used?
- Can users write any methods (including :AROUND, :BEFORE, etc) for
PRINT-OBJECT on type FLOAT?
If the answers to both of these questions end up being "Yes", then it
matters whether any of those format ops bind *PRINT-BASE* in order to
achieve the effect prescribed by CLtL of always printing floats in
base 10. If the answer to either of those questions is "No", then
it doesn't matter.
Comment on FUNCTION-COMPOSITION (Version 4, 12-Dec-88)
Barry Margolin's complaint about the degenerate case of COMPOSE should be
fixed in both proposals.
We prefer option NEW-FUNCTIONS.
We would vote "Yes" for COMPLEMENT-AND-ALWAYS iff NEW-FUNCTIONS fails.
Comment on FUNCTION-TYPE-REST-LIST-ELEMENT (Version 5, 14-Nov-88)
It turns out the list type specifier being contemplated wouldn't have
helped the case of alternating keyword value pairs because `repetitions'
were not among the issues being addressed by those working on that topic.
Comment on GET-MACRO-CHARACTER-READTABLE (Version 2, 8-Dec-88)
The proposal is ok, but the test case is wrong and should definitely be
fixed before a vote is called. EQness of successive results from
GET-MACRO-CHARACTER when given the same arguments is not guaranteed
currently, and the new proposal does not suggest causing such a thing.
Comment on HASH-TABLE-PACKAGE-GENERATORS (Version 7, 08-Dec-88)
The test-package-iterator example has the values from the generator in
the wrong order. This should be fixed before the actual vote.
Comment on HASH-TABLE-STABILITY (Version 1, 11-Nov-88)
We believe that it is not appropriate to vote on this issue at this
time. Neither of us had the patience to figure out in enough detail
what it was saying to have any confidence in our opinions on the issue.
If there is really something important going on here, it should be
possible to say briefly and in plain English what the problem being
addressed is and what the nature of the solution is. If, after a brief,
intelligible, high level discussion of the issue, details must be
presented to back up the high level goals, that would be fine.
Comment on HASH-TABLE-TESTS (Version 2, 08-Dec-88)
We would really like to see = hash tables, too.
Provision on IN-PACKAGE-FUNCTIONALITY (Version 4, 12-Dec-88)
Our "Yes" vote is contingent on the DEFPACKAGE passing.
Provision on LISP-SYMBOL-REDEFINITION (Version 5, 22-Nov-88)
We're reluctant to include the paragraph about permitting (DEFVAR CAR ...).
Our vote is "Yes" only if the paragraph suggesting this is permissible
is removed.
Comment on MAKE-PACKAGE-USE-DEFAULT (Version 2, 08-Oct-88)
We oppose this issue because:
- It is not clearly in the best interest of programmers in a supposedly
portable language to give up the most convenient package creation
syntax to a non-portable purpose.
- The justifications given in the proposal are not strong enough to
support an incompatible change like this.
- This is a special-case hack that does not generalize. There is
no way to create a package based on the implementation-dependent
default -and- other packages.
- It would be just as easy for someone to say
:USE (PACKAGE-USE-LIST (FIND-PACKAGE "USER"))
At least this technique generalizes.
- The Rationale uses incorrect suppositions to arrive at a false
generalization. Cloe doesn't have the asymmetry referred to.
- The current practice is not correct.
No mention of what Cloe does is attempted.
- Even allowing the default to be controlled by a variable does
not help because it encourages programs to be developed depending
on defaults which are not part of those programs, and therefore
works against portability.
- The Discussion section does not correctly reflect discussion.
For example, Pitman has repeatedly voiced strong opposition.
The Discussion mentions neither the fact that he objected nor the
reasons for his objection.
Comment on NTH-VALUE (Version 4, 08-Dec-88)
The proposal should clarify the treatment of n when it is out of range.
Any non-negative integer index values should be permitted.
NIL should result if the index argument is too large.
Comment on PACKAGE-CLUTTER (Version 6, 12-Dec-88)
This leaves implementations freedom to hack any properties other than
those in the LISP, KEYWORD, and USER packages. In fact, though, the
user should probably also have rights over the system in packages he
creates.
This will be an incompatible change -- possibly a major one -- for
Genera, which uses properties named by keywords and by symbols in the
LISP package. However, we think the change is worthwhile.
In general, Genera tries not to distinguish "the system" from "the user".
Anything the system is permitted to do, the user is permitted to do.
As such, we feel a little odd about placing restrictions on the system
which are not likewise placed on the user. In fact, if the system can
cause problems in this way, the user can, too. This proposal is only
heuristic. We're voting "Yes" because it's probably a change for the
better. But we won't be surprised if ultimately it is not seen to be
the right way to achieve the high-level goal.
LEXICAL, TYPE, INLINE, NOTINLINE, and FTYPE proclamations should be
explicitly ruled out (just as SPECIAL is) except that TYPE is allowed
if it's a CL variable, and FTYPE, INLINE, and NOTINLINE are allowed
if it's a CL function.
The DECLARATION proclamation probably be explicitly allowed (because
we see no reason not to permit it).
Comment on PEEK-CHAR-READ-CHAR-ECHO (Version 3, 08-Oct-88)
There are some typos in this proposal that need to be corrected.
Also, IIM asked for a clarification which seemed reasonable to us.
Comment on PROCLAIM-LEXICAL (Version 9, 08-Dec-88)
The proposal might want to define the status of unproclaimed free variables.
Presumably, we should say that they are an error, and we should encourage
compilers to issue a warning.
Comment on SETF-FUNCTION-VS-MACRO (Version 3, 04-Nov-87)
We think it's premature to vote on this issue at this time.
We suggest that a better proposal, unifying this issue with SETF-PLACES,
should be produced either before or during the upcoming meeting.
Comment on SETF-PLACES (Version 1, 11-Nov-88)
We think it's premature to vote on this issue at this time.
We suggest that a better proposal, unifying this issue with
SETF-FUNCTION-VS-MACRO, should be produced either before or during
the upcoming meeting.
Provision on STEP-ENVIRONMENT (Version 3, 20-Jun-88)
We don't understand
"it is acceptable for an implementation to interactively step
through only those parts of the evaluation that are interpreted."
There are a variety of ways to clarify this that would satisfy us.
Still, this must be clarified so we can know for sure what we're voting
on and have some confidence that other implementors will interpret it
in the same way as we have before we can vote "Yes".
Comment on STREAM-ACCESS (Version 2, 30-Nov-88)
Although requiring types instead of predicates forces the implementation
of these streams as separate types, there is no obvious serious problem
which can result from that, and it leaves open the possibility of writing
methods on particular types -- if they are also classes -- are they? The
proposal should spell this out.
Having both the types and the predicates is unnecessary clutter.
Omitting the predicates makes for less overhead with no lost functionality.
Provision on STREAM-INFO (Version 6, 30-Nov-88)
We vote "Yes" only if the name-changing amendment mentioned in the mail passes.
Also, the writeup incorrectly states that Newline is not a standard character;
Perhaps someone has confused "standard" with "graphic".
Comment on SUBTYPEP-TOO-VAGUE (Version 4, 07-Oct-88)
Some minor worry about DECLARE-FUNCTION-AMBIGUITY here since the proposal
mentions the list form of the FUNCTION declaration.
This is a complicated issue and we have not had time to think it through
as fully as we might like to have. Still, insofar as we have studied it,
it looks ok.
Provision on TAGBODY-CONTENTS (Version 5, 09-Dec-88)
The term "data element" is too vague in paragraph 2 of the proposal.
Our "Yes" vote is contingent on correcting this.
Moon doesn't really like allowing ignored frobs other than expressions
and tags, but is willing to live with the current proposal.
There several typos which should be fixed.
Comment on TAILP-NIL (Version 5, 09-Dec-88)
The EQ -> EQL change at the last minute means this is not Genera current
practice, contrary to the current practice section.
Provision on TEST-NOT-IF-NOT (Version 2, 05-Oct-88)
We are mostly happy with either of these proposals, with slight
preference to FLUSH-ALL. However, our "Yes" vote is contingent on:
- changing "remove" to "deprecate", and coming up with a
suitable policy for deprecation which allows a comfortable
transition from current practice.
- either of the FUNCTION-COMPOSITION proposals passing.
Provision on TYPE-OF-UNDERCONSTRAINED (Version 3, 12-Dec-88)
Our "Yes" vote is contingent on the following issues being addressed:
- RANDOM-STATE should be added to the list of built-in types.
- (subtypep (type-of x) (class-of x)) => T T for all x, seems to have
been intended but is not actually said. It should be added.
- The implementation recommendation in the discussion about returning
only portable type specifiers should be discarded.
- Shouldn't this refer to classes with proper names rather than just
ones with names?