Memorial Day Ballot

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

Memorial Day Ballot:

I was going to send these out in smaller doses, but a bunch of issues
built up and I decided that a real ballot would be easier.  A few more
issues will be sent out for consideration as soon as we have come up
with some coherent proposals and analyses.  Please reply by Wednesday
afternoon to FAHLMAN@CMUC and/or Common Lisp.

Recommendations in square brackets are by Scott Fahlman.
---------------------------------------------------------------------------
1. It is proposed that we eliminate PARSE-NUMBER from the manual.  

[I am strongly in favor of this.  This function is hard to document
properly, hard to implement in its full generality, and useless.  Most
of what this function does can be handled simply by calling READ on the
string.  Other cases, such as Teco-like integer prefixes, can easily be
handled by application-specific user functions to scan a string for the
first non-digit, etc.]
---------------------------------------------------------------------------
2. LOOP should create a BLOCK NIL around the TAGBODY, so that RETURN
works.

[I am strongly in favor.  If LOOP doesn't do this, the user will almost
always have to, and any future complex LOOP package would have to create
such blocks as well.]
---------------------------------------------------------------------------
3. Define GET-INTERNAL-TIME to get some implementation-dependent form of
runtime.  Add a second function, GET-REAL-TIME that returns some measure
of elapsed real time in the same internal-time format.  On some
machines, especially personal ones, these times will be identical, and
implementations may not be able to supply one or the other, but where
both are available (as on the Vax), there are legitimate needs for both.

[I am strongly in favor.]
---------------------------------------------------------------------------
4. The manual currently specifies (page 42, top) that the macros defined
in the white pages macros may expand into implementation-dependent code.
Some of them cannot be written without this freedom, but we don't want
these macros to expand into things that will preclude the writing of
portable code-walkers.  Therefore, it is proposed that this wording be
changed to allow implementation-specific functions to be produced, but
not new special forms.

[I am strongly in favor, unless someone comes up with a case where this
restriction would cause serious trouble for an implementation.]
---------------------------------------------------------------------------
5. If the special :allow-other-keys keyword is present in a call to a
keyword-taking function, it suppresses any unrecognized-keyword errors.
This is necessary so that pre-checked keyword lists can be passed
through a keyword-taking function to some other function that is called
by the first one without causing an error.

[I'm in favor.]
---------------------------------------------------------------------------
6.  In MULTIPLE-VALUE it is useful to have a way to discard unwanted
values.  Since you aren't binding, using and ignored variable is
inconvenient.  It is proposed that we follow the Lisp Machine here and
use NIL in place of a variable to mean "ignore this value".  For
consistency, this would work in MULTIPLE-VALUE-BIND as well, although it
is less useful there.

[Moon proposed this.  I'm mildly in favor, though I've oscillated on
this several times.]
---------------------------------------------------------------------------
7. Eliminate CATCH-ALL and UNWIND-ALL.

[Moon argues that these are worthless and should be flushed.  I agree.
These forms make a LOT of trouble for the implementor and are never
used.  Does anyone have an example of some real situation in which you
would need these?  If not, let's punt them.]
---------------------------------------------------------------------------
8. Since DEFMACRO is used to define special forms, some of which have
complex formats, it is proposed that we add destructuring to DEFMACRO
variable lists.  This would have to coexist with the current &mumble
indicators.  Destructuring works only to the left of the first & word;
from that point on, the varlist is parsed like a lambda list.

[My conservative instincts rebel at having destructuring and & words in
the same varlist, but I have gradually come around to the position that
this feature is worth any extra confusion it might cause (plus the
trouble of implementing it).  The simple cases that would really be used
will not be confusing.  So I favor this.]
---------------------------------------------------------------------------
9. It is proposed that DECLARE will be legal only at the start of
particular special forms, and that a new form, PROCLAIM, will be used at
top-level and in other places.  DECLARE will be undefined if encountered
in random places (though it may be defined as part of a compatibility
package).  The SPECIAL declaration is global if it appears within
PROCLAIM; it applies only to a particular binding and to references
within the scope of the form if it appears within a DECLARE.

[This issue (how to detect when a SPECIAL declaration is "top-level")
was debated on the Common Lisp list awhile back.  The proposal above, by
Moon, seemed the least objectionable to most of us at the time, and is
what we have implemented in the new Spice Lisp evaluator.  I favor it.]
---------------------------------------------------------------------------
10. The following was proposed by Moon:

The SVREF function and the (SIMPLE-VECTOR *) type are essentially
useless.  On stock hardware you cannot open-compile these, because
an implementation is required to provide (SIMPLE-VECTOR T),
(SIMPLE-VECTOR STRING-CHAR), and (SIMPLE-VECTOR BIT) types; hence
SVREF, without additional declarations, must do a run-time type
dispatch.  The useful function is SGVREF and the useful type
is (SIMPLE-VECTOR T), because these can be open-coded (and the
only distinction between VECTOR and SIMPLE-VECTOR is efficiency).
The SIMPLE-STRING and SIMPLE-BIT-VECTOR types are also useful,
but don't have special accessor functions.

Another way of putting this is that whether or not MAKE-ARRAY
returns a "simple" object should be allowed to depend on the
:ELEMENT-TYPE as well as the other keywords.

The phrase "simple general vector" is not euphonious.

Here's the proposal:

Retain the identity between the types (VECTOR type length)
and (ARRAY type (length)).  In other words, "vector" continues
to be a synonym for "1-dimensional array."

Eliminate SVREF and rename SGVREF to SVREF.  Eliminate the
type (SIMPLE-VECTOR type length), replacing it with
(SIMPLE-VECTOR length).  In other words, define a SIMPLE-VECTOR
to be a one-dimensional array of Lisp objects, creatable
by calling MAKE-ARRAY with only one dimension and with -none-
of its keywords except for :initial-element/:initial-contents.
In particular use of :element-type (other than T) makes it
non-simple (or, rather, permits the implementation to return
a non-simple-vector object but doesn't require it to.  Most
implementations would do the same thing for :element-type 'common
as for :element-type t).

In addition to SIMPLE-VECTOR we have SIMPLE-STRING and
SIMPLE-BIT-VECTOR.  Add auto-declaring accessor functions with names
SCHAR and SBIT (or something less horrid), to increase the symmetry.
SIMPLE-STRING is no longer a subtype of SIMPLE-VECTOR, even though
STRING is a subtype of VECTOR.  I don't believe this is a problem.

The type-specifier (SIMPLE-ARRAY element-type dimensions) refers to an array
created without the use of the :ADJUSTABLE, :FILL-POINTER, :DISPLACED-TO,
or :DISPLACED-INDEX-OFFSET keywords.  Such arrays are implemented
more efficiently in some implementations; thus a SIMPLE-ARRAY type
declaration may be used to get better code for array accesses.  Example:
	(DEFUN FFT (A)
	  (DECLARE (TYPE (SIMPLE-ARRAY SINGLE-FLOAT 2) A))
	  ...)

(SIMPLE-VECTOR n) == (SIMPLE-ARRAY T (n))
(SIMPLE-STRING n) == (SIMPLE-ARRAY STRING-CHAR (n))
(SIMPLE-BIT-VECTOR n) == (SIMPLE-ARRAY BIT (n))

The subtle note about declaration vs discrimination on page 33 of the
Laser edition applies.

SAREF probably shouldn't exist, since it would need to include the
element-type as an extra pseudo-argument, which would make the syntax
confusing.

Some implementations will choose to make the extension that :FILL-POINTER
is allowed when making a 1-dimensional simple array, so that they can have
SIMPLE-STRINGs with fill-pointers.  I don't know whether the manual ought
to mention this (probably not).

[ Despite my fear of re-opening the array debate, I believe that this is
such a win that it is worth that risk.  I am strongly in favor
of this proposal.  I just can't bring myself to type SGVREF. ]
---------------------------------------------------------------------------
11. Flush RESET-FILL-POINTER.  Add a new function FILL-POINTER, which
returns the active length of any vector that has a fill pointer.  This
is the same as what LENGTH returns, but it signals an error if the
object in question doesn't have a fill pointer.  SETF works on
FILL-POINTER.  The new value must be a non-negative integer not greater
than the dimension of the vector.

[I favor this.  RESET-FILL-POINTER is ugly.  SETF of LENGTH would be
confusing, since it would only work on a small fraction of the objects
on which LENGTH works.]
---------------------------------------------------------------------------
12. DEFSTRUCT must often created named vectors that are recognizable as
such.  There is currently no portable mechanism to do this, so DEFSTRUCT
must use implementation-dependent magic.  It would be nice if DEFSTRUCT
could be written entirely within Common Lisp.  It is proposed that we
add a :NAMED keyword to MAKE-ARRAY and MAKE-SIMPLE-VECTOR.  The argument
is the name itself, a symbol.  This argument is only legal if the array
is 1-D.

[I'm in favor.]
---------------------------------------------------------------------------
13. Reintroduce *IBASE*, but with a note that this should be used only
for compatibility packages and for reading files of data with the Lisp
reader.  Portable code should contain no regions of non-decimal radix;
individual non-decimal symbols may be read in using #O and friends.
We may want to rename this to *READ-BASE* if proposal 15 is adopted.

[I'm in favor, given these warnings.  There will be times when we really
need this.]
---------------------------------------------------------------------------
14. There are a few places where READ and READ-DELIMITED-LIST need to
behave differently according to whether or not they are "top-level"
calls to read.  For example, the scope of a set of #n# and #n= bindings
(or is it the extent?) is one top-level call to READ, so READ needs to
know whether it was called at top level or by a read-macro.  I propose
that we add two new functions, SUB-READ and SUB-READ-DELIMTED-LIST that
exactly parallel their counterparts, but that indicate non-top-level
calls to read -- such calls do not rebind the ## context, etc.

[I'm in favor.  An alternative proposal was to turn all the read
functions into keyword functions and add a :recursive keyword, but this
gets into some efficiency and clarity issues that I would prefer to
avoid.]
---------------------------------------------------------------------------
15. Propose that we rename *PRINfoo* to *PRINT-foo* for all foo, and
that *BASE* be renamed to *PRINT-BASE*.  In addition, the names of the
keyword arguments for WRITE would be changed from :PRINfoo to :foo.  So
one could say
	(WRITE X :BASE 8 :LEVEL 3 :LENGTH 5 :PRETTY T :RADIX T)
Finally, introduce *PRINT-READABLY*, a flag that when true causes
an error to be signalled if the LEVEL or LENGTH cutoff is about to
be applied or if #< syntax is about to be used.  That is, it refuses to
print something that cannot be read back in.

[I am strongly in favor of this.  The sole virtue of the old names was
Maclisp compatibility, and we blew that when we went for the asterisks.]
---------------------------------------------------------------------------
16. Guy proposes the following treatment of floating point in FORMAT:

	~w,d,pF
	~w,d,x,pE
	~w,d,pG

The meanings of the arguments are exactly as for the FORTRAN-77
language as described in chapter 13 of the FORTRAN-77 standard,
with the following exceptions and extensions:

(a) The scale factor p is an explicit parameter, rather than being
established be a separate preceding directive.  For ~F, p defaults to 0,
and for ~E and ~G it defaults to 1.  (In FORTRAN p always defaults
to 0.)

(b) If w is omitted, then the output is variable-width, and never
produces a field of asterisks; the other parameters are observed,
however.  So "~,2F" will always print exactly two digits after the
decimal point, and prints as many as necessary to the left of
the decimal point.

(c) If d is omitted then as many digits are produced as necessary
to preserve the information content of the number, except that if
w is specified then the width constraint it imposes overrides this
consideration.  (Thus if both are omitted we get free-format output.)

(d) The format operation formerly called ~G will henceforth be called ~@*.

(e) A separate proposal regarding ~$ is being developed.

[Looks good to me.  Something for everyone, just like Esperanto.]
---------------------------------------------------------------------------
17. Eliminate MAXPREFIX and MAXSUFFIX, which are redundant with
MISMATCH.  MISMATCH with non-null :FROM-END returns one plus the
index of the first position (from the right) in which the two sequences
do not match.  (The "one plus" is the new part.)

[I am strongly in favor.]
---------------------------------------------------------------------------
18. Moon proposes that we allow vertical bars around a symbol that
follows a : or #: package qualifier.

[I am in favor, unless this is a lot harder to implement than I think it
should be.  Do any of you reader-hackers out there have a strong
opinion?]
---------------------------------------------------------------------------
19. ~:A and ~:S should only affect the printing of NIL given directly
as an argument, not the printing of NILs inside a printed list.  This is
because these are for printing an object that is known to be a list, not
for printing data so it can be read compatibly into a N.I.L system.

[Proposed by Moon. I'm mildly in favor of this.]
---------------------------------------------------------------------------
20. APROPOS and PPRINT should return NIL so that they can be used at top
level from the terminal without having the returned value clobber the
stuff just printed.  Add a new function APROPOS-LIST that hands you a
list of the APROPOS symbols but prints nothing.

[I'm in favor.]
---------------------------------------------------------------------------
21. We need to indicate what package contains the symbols that are used
as elements of *features*.  It is proposed that we make these keywords.

[I'm in favor.]