The envelope please...

[Scott E. Fahlman <Fahlman@CMU-CS-C>]

Here is my interpretation of the results of the Memorial Day ballot.
A number of new issues have been raised since this went out, so there
will be another small ballot going out tomorrow.

Note that the raw vote-count doesn't decide the issue here.  One good
argument pointing out why something is unworkable is stronger than any
number of "OK, I'll go along with the proposal" votes, especially if
those votes came before the argument.  On questions of mechanics, people
speaking for an implementation group carry more weight than others.  On
questions of taste, the process is pretty democratic, but perhaps
weighted slightly for experience.  Again, in matters of taste, a cogent
argument carries extra weight.

The result, then, must be somewhat subjective.  My goal here is to come
up with a solution that we all can live with and to do so with a minimum
of futher iteration.  If there's some wiggle room left within those
bounds, then I try to find the solution that best satisfies the
aggregate taste of the community.

If any of the decisions made here strikes you as something that you just
cannot live with, let me know right away.  But before you complain,
think about the fact that getting the manual completed and out very soon
is extremely important to some of the implementation efforts.

-- Scott
--------------------------------------------------------------------------
1. Flush PARSE-NUMBER: APPROVED.  Glenn Burke has proposed a much
simpler PARSE-INTEGER function which does most of what PARSE-NUMBER
would have been used for and which is trivial to implement.  This will
be on tomorrow's ballot.
--------------------------------------------------------------------------
2. LOOP makes a BLOCK NIL: APPROVED.
--------------------------------------------------------------------------
3. Split GET-INTERNAL-TIME into two functions, one to get real time and
one to get runtime.  This was poorly explained on the original ballot,
and there were some objections by people who clearly had misunderstood
the proposal.  Among the rest of the responses, there seemed to be no
opposition to the proposal, but a number of people pointed out that my
proposed names were losers.  I'm going to treat the proposal as being
APPROVED unless someone explodes.

To reiterate, these functions are for low-level, fine-grained metering
of perfomance.  They need to be quick and do not want to be loaded down
with keywords or other hair.  Each returns an integer that is the real
time or run time since some arbitrary starting point.  The size of the
tick is implementation-dependent and is indicated by the constant
INTERNAL-TIME-UNITS-PER-SECOND.

The best names I've heard so far are GET-INTERNAL-RUN-TIME and
GET-INTERNAL-REAL-TIME.  These are verbose, but that's not too bad since
these are low-level functions that will seldom be typed at the terminal.
The names evoke the familiar concepts of runtime and real time, but also
emphasize the link to the INTERNAL-TIME-UNITS-PER-SECOND constant.
Also, the names are similar in form, which is important for functions so
similar to one another.  If anyone comes up with a better pair of names in
the next day or so, those will be used.  Otherwise, these names will be
used.
---------------------------------------------------------------------------
4. Built-in macros cannot expand into implementation-dependent special
forms.  REJECTED.  This is one of the areas where negative comments by
implementors carried extra weight.  There was a lot of support for the
view that this restriction, while not impossible, would cause
considerable grief for implementors.  There were also many comments that
portable code-walkers just need some sort of mechanism for describing
new special forms.
---------------------------------------------------------------------------
5. The :allow-other-keywords proposal: APPROVED.
---------------------------------------------------------------------------
6. NIL means "ignore this value" in MULTIPLE-VALUE: REJECTED.  Basically
a taste issue.  There was some sentiment both ways, but more in favor of
not doing this.  (My vote has gone negative on this, on the grounds that
MULTIPLE-VALUE will not be used much compared to MULTIPLE-VALUE-BIND.  A
little extra convenience in a few cases is not sufficient to justify a
confusing exception.)
---------------------------------------------------------------------------
7. Flush CATCH-ALL and UNWIND-ALL: APPROVED.  Nobody came up with a case
in which these were clearly needed (modulo some confusion between THROW
and condition signalling) and a substantial majority favored eliminating
them.
---------------------------------------------------------------------------
8. Let DEFMACRO destructure: APPROVED.  A couple of people objected on
the grounds that destructuring can lead to confusing lambda-lists, and a
couple of others suggested that destructuring should be applied to the
lambda-lists of functions as well.  (I am violently opposed to the
latter suggestion.)  Most people seemed to agree with Moon that
destructuring makes sense in defmacro, since it is used to create macros
that behave like special forms.  I take it that the proposal most people
favor is the one that allows destructuring (of lists or dotted lists,
not vectors and other odd items) in any place where a regular lambda-list
accepts a variable.
---------------------------------------------------------------------------
9. Moon's PROCLAIM proposal: APPROVED.  A couple of people referred to
an earlier demonstration that the split was not necessary if you were
willing to forego error checking, but most favored the change.  Some
people suggested that PROCLAIM should be a function, not a special form.
This will be an item on tomorrow's ballot.
---------------------------------------------------------------------------
10. Moon's Simple-Vector proposal: APPROVED.
---------------------------------------------------------------------------
11. Replace RESET-FILL-POINTER with SETF of FILL-POINTER: APPROVED.
---------------------------------------------------------------------------
12. Add :NAMED to MAKE-ARRAY: REJECTED.  Withdrawn by Moon, who proposed
it.  A more complex proposal by GSB will appear on tomorrow's ballot.
---------------------------------------------------------------------------
13. *IBASE* to be reincarnated as *READ-BASE*: APPROVED.
---------------------------------------------------------------------------
14. SUB-READ: REJECTED.  One or more replacement proposals will appear on
tomorrow's ballot, since the current situation is unworkable.
---------------------------------------------------------------------------
15. *PRINmumble* => *PRINT-MUMBLE*: APPROVED.
---------------------------------------------------------------------------
16. Fortran-type ~E, ~F, ~G: APPROVED.  I sense a general willingness to
let Steele and Moon bash out the details on this (as long as
overflowing fields don't go onto the next line).
---------------------------------------------------------------------------
17. Flush MAXPREFIX, MAXSUFFIX, and change the value returned by
MISMATCH :FROM-END.  APPROVED.
---------------------------------------------------------------------------
18. Allow vertical bars around qualified symbols: DEFERRED.  The
additional proposal to treat both halves of package:symbol the same with
respect to case seems to be agreeable to most people, but I'll put this
and some other suggestions on tomorrow's ballot.
---------------------------------------------------------------------------
19. ~:A and ~:S change the printing of NIL only for the whole argument,
not for sub-forms: APPROVED.
---------------------------------------------------------------------------
20. Do not return the argunet as the value of PPRINT or APROPOS:
APPROVED, but return no value instead of NIL.  The choice of NIL was
mine because I am still uncomfortable around functions that refuse to
speak to me, except in the third person, but clearly the rest of you
feel otherwise.
---------------------------------------------------------------------------
21. The symbols on the *FEATURES* should be keywords: REJECTED.  People
were generally indifferent to this issue until Benson made explicit the
issue of either having to type #+:foo or fudging #+ to look things up in
odd ways.  Since then, sentiment has been running strongly in favor of
allowing any symbol (or indeed any Lisp object, presumably assuming an
EQ test) in this list.  Several people (including me) have changed their
earlier votes to this new position.  I take this as latter proposal as
being approved, and the original as being rejected.