[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Kim A. Barrett <IIM@ECLA.USC.EDU>: Ballot reply]
- To: cl-cleanup@sail.stanford.edu
- Subject: [Kim A. Barrett <IIM@ECLA.USC.EDU>: Ballot reply]
- From: masinter.pa@Xerox.COM
- Date: 2 Jan 89 14:42 PST
Hi -- I'm reading answering the volumes of mail I have in a fairly random
order, so things will come out of sync.
Some ballots came in only to me, so I'm forwarding them to the entire
committee, and will prepare a summary/status report.
----- Begin Forwarded Messages -----
Return-Path: <IIM@ECLA.USC.EDU>
Received: from ECLA.USC.EDU ([26.21.0.65]) by Xerox.COM ; 01 JAN 89
05:11:50 PST
Date: Sat, 31 Dec 88 19:53:52 PST
From: Kim A. Barrett <IIM@ECLA.USC.EDU>
Subject: Ballot reply
To: masinter.pa
cc: iim@ECLA.USC.EDU
Message-ID: <12458960461.23.IIM@ECLA.USC.EDU>
Larry,
Here is my response to the cleanup ballot. This can be considered the
'official' position of IIM. I've included extensive comments on a few
issues.
I consider some of these issues controversial, and not appropriate to a
block
vote. I've commented on some of them as to why I think they have problems.
I'm going to send these comments out for general distribution so that
people
can respond, but I'm also including them here to help you tell which ones
I'm
just voting yes/no on and which ones I think need further work or should be
voted separately.
I have not voted on the following issues because I don't have a copy of the
current proposal to read. If I can obtain copies of them in time I'll send
a
seperate response for just them. Yes, I know about /clcleanup/pending on
arisia, but repeated FTP attempts haven't gotten me anywhere.
kab
===============================================================================
ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING
CLOSED-STREAM-OPERATIONS:ALLOW-INQUIRY
DECLARE-FUNCTION-AMBIGUITY:DELETE-FTYPE-ABBREVIATION
DECLARE-TYPE-FREE:ALLOW
FUNCTION-DEFINITION:FUNCTION-SOURCE
GET-MACRO-CHARACTER-READTABLE:NIL-STANDARD
HASH-TABLE-PACKAGE-GENERATORS:ADD-WITH-WRAPPER
HASH-TABLE-TESTS:ADD-EQUALP
LAMBDA-FORM:NEW-MACRO
LCM-NO-ARGUMENTS:1
LISP-SYMBOL-REDEFINITION:DISALLOW
NTH-VALUE:ADD
PACKAGE-DELETION:NEW-FUNCTION
PATHNAME-TYPE-UNSPECIFIC:NEW-TOKEN
RANGE-OF-COUNT-KEYWORD:NIL-OR-INTEGER
RETURN-VALUES-UNSPECIFIED:SPECIFY
SETF-FUNCTION-VS-MACRO:SETF-FUNCTIONS
SETF-PLACES:ADD-SETF-FUNCTIONS
STREAM-ACCESS:ADD-TYPES-PREDICATES-ACCESSORS
STREAM-INFO:ONE-DIMENSIONAL-FUNCTIONS
SYMBOL-MACROLET-DECLARE:ALLOW
TAGBODY-CONTENTS:FORBID-EXTENSION
TEST-NOT-IF-NOT:FLUSH-ALL
TEST-NOT-IF-NOT:FLUSH-TEST-NOT
VARIABLE-LIST-ASYMMETRY:SYMMETRIZE
===============================================================================
And now for the voting ...
===============================================================================
ARGUMENTS-UNDERSPECIFIED:SPECIFY
Version 4, 21-Sep-88, Mailed 4 Dec 88
YES
===============================================================================
CONTAGION-ON-NUMERICAL-COMPARISONS:TRANSITIVE
Version 1, 14-Sep-88, Mailed 6 Oct 88
YES
===============================================================================
DECLARATION-SCOPE:NO-HOISTING
DECLARATION-SCOPE:LIMITED-HOISTING
Version 4, 15-Nov-88, Mailed 9-Dec-88
NO on both proposals.
I really don't like NO-HOISTING because it is too imcompatible. I think I
could live with LIMITED-HOISTING, but I'm unconvinced of the need for such
an
incompatible change. All of the problem examples are easily solved by
simply
changing some of the variable names.
===============================================================================
DECODE-UNIVERSAL-TIME-DAYLIGHT:LIKE-ENCODE
Version 2, 30-Sep-88, Mailed 6 Oct 88
YES
===============================================================================
DEFPACKAGE:ADDITION
Version 7, 2-Nov-88, Mailed 5 Dec 88
YES
===============================================================================
DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE:ALLOW-KEY
Version 2, 21-Sep-88, Mailed 6 Oct 88
While I support the concept, the wording needs cleanup. If these problems
are
fixed, then I'll vote YES.
1. The proposal explicitely says to allow &OPTIONAL, &KEY, and &AUX
keywords,
but fails to mention &REST and &ALLOW-OTHER-KEYS.
2. The proposal does not say how defaulting is to be done when the
programmer
doesn't supply a default value for a keyword argument. I assume that the
intent is that it will do defaulting in the same way &OPTIONAL arguments
are
specified to default in CLtL, ie. if no default is supplied in the
lambda-list
then use the slot initform, else undefined.
3. The proposal does not say which of key/var gets matched to the slot name
in
keyword parameter specifiers of the form ((key var) [default [svar]]). I
assume that it should be var that gets matched, since that gives the
programmer
the most options, but this needs to be stated explicitely.
Note for Current Practice: The latest version of IIM Common Lisp
implements
this.
===============================================================================
DEFSTRUCT-PRINT-FUNCTION-INHERITANCE:YES
Version 3, 7 Dec 88, Mailed 12-Dec-88
YES
===============================================================================
DEFSTRUCT-SLOTS-CONSTRAINTS-NAME:DUPLICATES-ERROR
Version 4, 31-Oct-88, Mailed 12-Dec-88
YES
===============================================================================
DESCRIBE-INTERACTIVE:EXPLICITLY-VAGUE
DESCRIBE-INTERACTIVE:NO
Version 4, 15-Nov-88 , Mailed 7-Dec-88
EXPLICITLY-VAGUE: ABSTAIN
NO: YES
I sort of agree with the arguments for disallowing interaction, but I won't
be
too upset if the NO proposal gets shot down and we have to go to
EXPLICTLY-VAGUE.
===============================================================================
DOTTED-MACRO-FORMS:ALLOW
Version 3, 15-Nov-88, Mailed 7-Dec-88
YES
===============================================================================
EQUAL-STRUCTURE:STATUS-QUO
Version 5, 1-Oct-88, Mailed 8 Oct 88
I thought this had been pretty well hashed out, so I was surprised to find
some
serious problems with the proposal. While I support the general idea of
the
proposal, I can't vote in favor of it in its current form. If these things
get
cleaned up, then I'll vote YES. Note that all of my problems with the
current
proposal have to do with EQUALP; I agree with the proposal for EQUAL, and
would
vote YES for it as a seperate issue if the EQUALP stuff can't be resolved
in
time.
1. The description of EQUALP's behavior does not match CLtL, since it
references EQUAL more than it ought. Specifically, characters should be
compared with CHAR-EQUAL, and numbers should be compared with =, while the
proposal says EQL for numbers (by defaulting to EQUAL) and is ambiguous
about
characters (could be EQL (by defaulting to EQUAL) or CHAR-EQUAL (since
string
comparisons are case insensitive)).
2. The proposal says EQUALP descends arrays, structures, and instances, but
uses EQ on other types, and gives hash-tables as an example of a data type
which is not descended. What if, in a given implementation, hash-tables
are
implemented using structures or instances. Does this mean that such an
implementation must include code in EQUALP to explicitely prevent
descending
into hash-tables (and presumably any other COMMON types which are
implemented
using structures or instances)? This question has to be answered if the
use of
EQUALP is to have any chance of being portable when applied to such
objects.
===============================================================================
EXIT-EXTENT:MINIMAL
EXIT-EXTENT:MEDIUM
Version 5, 12-Dec-88, Mailed 12-Dec-88
MINIMAL: NO, for reasons I have discussed on the mailing list. Basically,
I
feel this seriously damages the semantics of the language, playing havoc
with
both UNWIND-PROTECT and the definition of dynamic-scope.
MEDIUM: Currently NO, even though the intent of this proposal is what I
want,
because the current proposal is poorly written. I don't believe it is
really
ready for voting yet. I agree with Moon's comment that this may be hard to
write in a reasonably implementation-independent way. My intuition is
based on
the nesting of forms, but I'm not sure how constraining a writup based on
that
would be (though obviously somewhat, since the technique Symbolic's uses is
invalidated by acceptence of something like this proposal).
===============================================================================
EXPT-RATIO:P.211
Version 3, 31-Oct-88, Mailed 7 Dec 88
YES
===============================================================================
FIXNUM-NON-PORTABLE:TIGHTEN-DEFINITION
FIXNUM-NON-PORTABLE:TIGHTEN-FIXNUM-TOSS-BIGNUM
Version 4, 7-Dec-88, Mailed 12-Dec-88
NO on both.
Basically, I don't think either proposal really addresses the problem
adequately. I'm looking at this from the point of view of someone who has
dealt with porting C programs between machines with different native word
sizes, and therefor different definitions of the 'int' type. I see many of
the
same kinds of problems here, and the approach being taken by these
proposals
really doesn't do anything about them.
Actually, I think a case could be made in favor of a third proposal,
TOSS-FIXNUM-TOSS-BIGNUM, making it explicit that neither is portable. I'm
not
planning to put this forward as a serious proposal though, since I expect
it
would go over like a lead balloon for historical reasons if nothing else.
There are relatively few legitimate uses of FIXNUM in portable code, and
legislating the definition of FIXNUM in a fairly ad hoc way is not going to
improve the situation. About the only place the FIXNUM type specifier
should
appear in portable code is as part of the definition of a type used by the
portable code, with the definition parameterized according to the
implementation being ported to. Even there it is probably better to use
ranged
integer type specifiers.
===============================================================================
FORMAT-E-EXPONENT-SIGN:FORCE-SIGN
Version 2, 2 Oct 88, Mailed 6 Oct 88
YES
===============================================================================
FORMAT-PRETTY-PRINT:YES
Version 7, 15 Dec 88, Mailed 7 Dec 88
YES
===============================================================================
FUNCTION-COMPOSITION:NEW-FUNCTIONS
FUNCTION-COMPOSITION:COMPLEMENT-AND-ALWAYS
Version 4, 12 Dec 88, Mailed 12 Dec 88
NEW-FUNCTIONS: NO. I agree with some of the discussion that this is an
inadequate set of operators, it is untested by the community, and serves no
visible need. Encourage people to add extensions like this, and we'll see
what
results when we do CL9x (or CL2001).
COMPLEMENT-AND-ALWAYS: YES. I can see COMPLEMENT being a useful standard
shorthand that makes the removal of the :test-not and -if-not stuff more
palatable.
===============================================================================
FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS:RESTRICTIVE
Version 3, 7-Dec-88, Mailed 12-Dec-88
YES
===============================================================================
FUNCTION-TYPE-REST-LIST-ELEMENT:USE-ACTUAL-ARGUMENT-TYPE
Version 5, 14-Nov-88 , Mailed 8-Dec-88
NO
===============================================================================
HASH-TABLE-STABILITY:KEY-TRANSFORM-RESTRICTIONS
Version 1, 11-Nov-88 , Mailed 12 Dec 88
YES.
There is a minor glitch in an aside that needs to be fixed. Paragraph 3 of
item 3 says that the following code would be acceptable as the <sxh>
function
for EQL tables:
(if (numberp x) (sxhash x) (%unique-no x))
In general, the NUMBERP test really should be (OR (NUMBERP X) (CHARACTERP
X)),
to correspond properly to the definition of EQL.
===============================================================================
IN-PACKAGE-FUNCTIONALITY:SELECT-ONLY
Version 4, 12-Dec-88, Mailed 12-Dec-88
YES
===============================================================================
MAKE-PACKAGE-USE-DEFAULT:IMPLEMENTATION-DEPENDENT
Version 2, 8 Oct 88, Mailed 12-Dec-88
NO
===============================================================================
MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE
Version 2, 09-Jun-88, Mailed 8 Oct 88
YES
===============================================================================
PACKAGE-CLUTTER:REDUCE
Version 6, 12-Dec-88, Mailed 12-Dec-881
YES, but note such that symbols which are documented special-forms are also
FBOUNDP.
===============================================================================
PEEK-CHAR-READ-CHAR-ECHO:FIRST-READ-CHAR
Version 3, 8-Oct-88, Mailed 8 Oct 88
YES
However, I think it should be mentioned that this implies that PEEK-CHAR is
really no longer equivelent to read-char followed by unread-char, and can't
be
implemented that way for any kind of metastream. All metastreams must now
support PEEK-CHAR directly, and pass it along to the indirect streams, in
case
some of those streams are echo streams. This mostly increases the cost to
implementors, though it is also a cost to users in systems where the set of
metastreams is user-extensible.
===============================================================================
PRINT-CIRCLE-STRUCTURE:USER-FUNCTIONS-WORK
Version 3, 20 Sep 88, Mailed 8 Oct 88
YES
===============================================================================
PROCLAIM-LEXICAL:LG
Version 9, 8-Dec-88, Mailed 12-Dec-88
===============================================================================
RANGE-OF-START-AND-END-PARAMETERS:INTEGER-AND-INTEGER-NIL
Version 1, 14-Sep-88, Mailed 7 Oct 88
YES
===============================================================================
REQUIRE-PATHNAME-DEFAULTS:ELIMINATE
Version 6, 9 Dec 88, mailed 09 Dec 88
YES
===============================================================================
REST-LIST-ALLOCATION:NEWLY-ALLOCATED
REST-LIST-ALLOCATION:MAY-SHARE
REST-LIST-ALLOCATION:MUST-SHARE
Version 3, 12-Dec-88, mailed 12-Dec-88
NEWLY-ALLOCATED: NO
MUST-SHARE: NO
I feel that both of these take away too much implementation freedom. Which
leaves us with ...
MAY-SHARE: YES.
But I'd like to see something added that allows the programmer to force
copying
when she cares, without requiring an explicit call to COPY-LIST (possibly
featurized). Note that most cases of COPY-LIST on &REST parameters that
I've
seen had nothing to do with the question of whether apply => &rest could
share;
they were put in to deal with implementations which always stack-cons &rest
lists.
===============================================================================
ROOM-DEFAULT-ARGUMENT:NEW-VALUE
Version 1 12-Sep-88 mailed 8 Oct 88
YES
I liked KMP's suggestion of defining additional synonyms:
:short == nil
:medium == :default
:long == t
This could be done as a seperate proposal, but hardly seems worth the
effort.
===============================================================================
SETF-SUB-METHODS:DELAYED-ACCESS-STORES
Version 5, 12-Feb-88 mailed 8 Oct 88
YES
===============================================================================
STANDARD-INPUT-INITIAL-BINDING:DEFINED-CONTRACTS
Version 8, 8 Jul 88, Mailed 7 Oct 88
YES
===============================================================================
STEP-ENVIRONMENT:CURRENT
Version 3, 20-Jun-88, mailed 7 Oct 88
I have no problem with TIME behaving as proposed. I have serious problems
with
STEP though, as far as compiled behavior. I don't agree that it is easy to
get
the environment right in this case, because it would require the
interpreter to
handle compiler data structures, which might not even be possible. Maybe
I'm
misunderstanding what is wanted for compiled STEP. If what is wanted is
that
execution of interpreted code which occurs within the context of the STEP
macro
should be stepped, then that's ok, and I'll vote YES.
===============================================================================
SUBTYPEP-TOO-VAGUE:CLARIFY
Version 4, 7-Oct-88, mailed 7 Oct 88
YES
===============================================================================
SYMBOL-MACROLET-SEMANTICS:SPECIAL-FORM
Version 5, 30-Nov-88, mailed 9 Dec 88
YES
===============================================================================
TAILP-NIL:T
Version 5, 9-Dec-88, mailed 12-Dec-88
YES
===============================================================================
TYPE-OF-UNDERCONSTRAINED:ADD-CONSTRAINTS
Version 3, 12-Dec-88, mailed 12 Dec 88
(some "bugs" in the proposal)
YES, assuming bugs are fixed. Include Moon's phrasing of the constraint I
brought up: (SUBTYPEP (TYPE-OF X) (CLASS-OF X)) => T T, for all X.
===============================================================================
UNREAD-CHAR-AFTER-PEEK-CHAR:DONT-ALLOW
Version 2, 2-Dec-88, mailed 12-Dec-88
YES
-------
----- End Forwarded Messages -----