My replies to Memorial Day Ballot

[Guy.Steele@CMU-CS-A]

I am in favor of all the proposed changes except numbers 6, 14, and 18.
I also have a remark on issue 7.

6: I am not convinced that the bit of convenience in MULTIPLE-VALUE
is worth the odd exception in the syntax, particularly if it is
allowed to propagate to MULTIPLE-VALUE-BIND.  Also, just as LET
is in many cases preferable to SETQ anyway, so MULTIPLE-VALUE-BIND
is often preferable to MULTIPLE-VALUE anyway, in which case IGNORE
declarations do the job.  Therefore I am opposed to this proposal,
though not strongly.

7: CATCH-ALL and UNWIND-ALL are currently the only means for trapping
any throw and being able to decide what it is.  (UNWIND-PROTECT does
not have the latter property.)  However, it may be best to omit these
until we have yet more experience with what we really want.
UNWIND-PROTECT does 90% of the job.

14: There are at least three reasons to distinguish a "top-level"
read from an "internal" call:
(a) A top-level call establishes the "preserve whitespace" flag, and
an internal call does not modify it.
(b) A top-level call establishes a scope for the #n= and #n# syntax.
(c) A top-level call establishes the exit point for EOF errors.
While introducing two new functions (copies of the "READ-like" functions)
solves the first two problems, it does not solve the third.  It is
also necessary to distinguish betwene top-level and internal calls
to READ-CHAR and READ-LINE and others for the purposes of EOF handling.
Also, it is undesirable for new user-written parsing functions to
have to come intwo flavors.  I think it is better to have a standard
simple protocol for distinguishing between top-level and internal calls.
It does seem rather unpleasant to have to go to keyword syntax for all
the input functions.
Here is another possibility: let the eof-errorp parameter take on one
oif three values.  NIL means it is an internal call.  :VALUE means
that EOF causes the eof-value to be returned.  :ERROR means an error
should be signalled.  If an "internal call" is performed when there is
no surrounding "top-level" call, then it is as if :ERROR had been
specified.  NIL is the default value for eof-errorp.

18: I agree that it is desirable to allow | syntax in package-prefixed names,
but this proposal does not cover all the cases.  What about odd characters
in package names?  May | syntax be used there too?
I have a counter-proposal.  | syntax may surround the *entire name*
of a symbol.  It is as if every character between the vertical bars
had been preceded by a \, except for the characters |, \, and (here is
the proposed change!) :.  Any occurrence of any of these three characters
must nevertheless always be preceded by a \.
It may seem awful to require any : to be preceded by a \.  It would have
been in MacLISP, where |-symbols were also used as strings.  This is not
a problem in COmmon LISP.
As an example, the symbol in package "S P A C E S" whose name is
"::=" could be written as     |S P A C E S:\:\:=|
The advantage of this proposal is that it allows | to continue to be
an ordinary macro character with screwing up the tokenizer.
Note that that keyword whose name was "foo" (lowercase) would be
written |:foo|, not :|foo|.  Vertical bars would always completely
surround the entire other syntax for the symbol, and are described
by the simple rule of quoting every character except |, \, and :.

--Guy