[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
My replies to Memorial Day Ballot
- To: fahlman@CMU-CS-C
- Subject: My replies to Memorial Day Ballot
- From: Guy.Steele@CMU-CS-A
- Date: Mon, 30 May 1983 18:59:00 -0000
- Cc: common-lisp@SU-AI
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 :.