[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Kim A. Barrett <IIM@ECLA.USC.EDU>: Ballot reply]
- To: email@example.com
- 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 -----
Received: from ECLA.USC.EDU ([18.104.22.168]) by Xerox.COM ; 01 JAN 89
Date: Sat, 31 Dec 88 19:53:52 PST
From: Kim A. Barrett <IIM@ECLA.USC.EDU>
Subject: Ballot reply
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
I consider some of these issues controversial, and not appropriate to a
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
can respond, but I'm also including them here to help you tell which ones
just voting yes/no on and which ones I think need further work or should be
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
seperate response for just them. Yes, I know about /clcleanup/pending on
arisia, but repeated FTP attempts haven't gotten me anywhere.
And now for the voting ...
Version 4, 21-Sep-88, Mailed 4 Dec 88
Version 1, 14-Sep-88, Mailed 6 Oct 88
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
incompatible change. All of the problem examples are easily solved by
changing some of the variable names.
Version 2, 30-Sep-88, Mailed 6 Oct 88
Version 7, 2-Nov-88, Mailed 5 Dec 88
Version 2, 21-Sep-88, Mailed 6 Oct 88
While I support the concept, the wording needs cleanup. If these problems
fixed, then I'll vote YES.
1. The proposal explicitely says to allow &OPTIONAL, &KEY, and &AUX
but fails to mention &REST and &ALLOW-OTHER-KEYS.
2. The proposal does not say how defaulting is to be done when the
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
specified to default in CLtL, ie. if no default is supplied in the
then use the slot initform, else undefined.
3. The proposal does not say which of key/var gets matched to the slot name
keyword parameter specifiers of the form ((key var) [default [svar]]). I
assume that it should be var that gets matched, since that gives the
the most options, but this needs to be stated explicitely.
Note for Current Practice: The latest version of IIM Common Lisp
Version 3, 7 Dec 88, Mailed 12-Dec-88
Version 4, 31-Oct-88, Mailed 12-Dec-88
Version 4, 15-Nov-88 , Mailed 7-Dec-88
I sort of agree with the arguments for disallowing interaction, but I won't
too upset if the NO proposal gets shot down and we have to go to
Version 3, 15-Nov-88, Mailed 7-Dec-88
Version 5, 1-Oct-88, Mailed 8 Oct 88
I thought this had been pretty well hashed out, so I was surprised to find
serious problems with the proposal. While I support the general idea of
proposal, I can't vote in favor of it in its current form. If these things
cleaned up, then I'll vote YES. Note that all of my problems with the
proposal have to do with EQUALP; I agree with the proposal for EQUAL, and
vote YES for it as a seperate issue if the EQUALP stuff can't be resolved
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
characters (could be EQL (by defaulting to EQUAL) or CHAR-EQUAL (since
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
implemented using structures or instances. Does this mean that such an
implementation must include code in EQUALP to explicitely prevent
into hash-tables (and presumably any other COMMON types which are
using structures or instances)? This question has to be answered if the
EQUALP is to have any chance of being portable when applied to such
Version 5, 12-Dec-88, Mailed 12-Dec-88
MINIMAL: NO, for reasons I have discussed on the mailing list. Basically,
feel this seriously damages the semantics of the language, playing havoc
both UNWIND-PROTECT and the definition of dynamic-scope.
MEDIUM: Currently NO, even though the intent of this proposal is what I
because the current proposal is poorly written. I don't believe it is
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
the nesting of forms, but I'm not sure how constraining a writup based on
would be (though obviously somewhat, since the technique Symbolic's uses is
invalidated by acceptence of something like this proposal).
Version 3, 31-Oct-88, Mailed 7 Dec 88
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
same kinds of problems here, and the approach being taken by these
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
planning to put this forward as a serious proposal though, since I expect
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
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
integer type specifiers.
Version 2, 2 Oct 88, Mailed 6 Oct 88
Version 7, 15 Dec 88, Mailed 7 Dec 88
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
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
Version 3, 7-Dec-88, Mailed 12-Dec-88
Version 5, 14-Nov-88 , Mailed 8-Dec-88
Version 1, 11-Nov-88 , Mailed 12 Dec 88
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>
for EQL tables:
(if (numberp x) (sxhash x) (%unique-no x))
In general, the NUMBERP test really should be (OR (NUMBERP X) (CHARACTERP
to correspond properly to the definition of EQL.
Version 4, 12-Dec-88, Mailed 12-Dec-88
Version 2, 8 Oct 88, Mailed 12-Dec-88
Version 2, 09-Jun-88, Mailed 8 Oct 88
Version 6, 12-Dec-88, Mailed 12-Dec-881
YES, but note such that symbols which are documented special-forms are also
Version 3, 8-Oct-88, Mailed 8 Oct 88
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
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
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.
Version 3, 20 Sep 88, Mailed 8 Oct 88
Version 9, 8-Dec-88, Mailed 12-Dec-88
Version 1, 14-Sep-88, Mailed 7 Oct 88
Version 6, 9 Dec 88, mailed 09 Dec 88
Version 3, 12-Dec-88, mailed 12-Dec-88
I feel that both of these take away too much implementation freedom. Which
leaves us with ...
But I'd like to see something added that allows the programmer to force
when she cares, without requiring an explicit call to COPY-LIST (possibly
featurized). Note that most cases of COPY-LIST on &REST parameters that
seen had nothing to do with the question of whether apply => &rest could
they were put in to deal with implementations which always stack-cons &rest
Version 1 12-Sep-88 mailed 8 Oct 88
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
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
I have no problem with TIME behaving as proposed. I have serious problems
STEP though, as far as compiled behavior. I don't agree that it is easy to
the environment right in this case, because it would require the
handle compiler data structures, which might not even be possible. Maybe
misunderstanding what is wanted for compiled STEP. If what is wanted is
execution of interpreted code which occurs within the context of the STEP
should be stepped, then that's ok, and I'll vote YES.
Version 4, 7-Oct-88, mailed 7 Oct 88
Version 5, 30-Nov-88, mailed 9 Dec 88
Version 5, 9-Dec-88, mailed 12-Dec-88
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.
Version 2, 2-Dec-88, mailed 12-Dec-88
----- End Forwarded Messages -----