mem. day ballot

[Glenn S. Burke <GSB @ MIT-ML>]

1. Eliminate parse-number.
	Have parse-integer, as bernie suggested.  This will eliminate
	all those dumb loops everyone seems to write all the time, and
	will also presumably have less overhead than a general read.
2. BLOCK NIL for LOOP
	Yes.
3. get-internal-time/get-real-time
	Sure, but i find the names (the contrast between them) disconcerting.
	It sounds like they are different units.  ("internal" sounds like
	an internal representation, whereas "real" does not.)  I have no
	alternate suggestion, and don't care all that much.
4. Eliminate implementation-dependent special-forms in macro-expansion.
	I guess i can accept this, although i would prefer to have a
	template-driven code-walker so that this would not be necessary.
	(As it is, i have many special forms which aren't even defined
	in the interpreter;  they exist only to get the compiler to do
	some fancy things for special low-level code which never runs
	interpreted.)
5. :allow-other-keys
	OK.
6.  NIL in multiple-value[-bind]
	Yes.
7. Eliminate CATCH-ALL and UNWIND-ALL.
	No opinion, i haven't thought about them or implemented them.
8. defmacro destructuring
	The whole thing should be subject to destructuring, including
	those positions in &mumbles which are unambiguous variable
	positions.  I strongly suggest that we standardize on a
	primitive to do a destructuring bind in this manner, with syntax
	(name pattern value . body).  I can't think up a good name, but
	it should not be rooted in LET.  My experience with having
	LET do this type of destructuring is that it is a pain to do
	multiple "parallel" destructurings, and also that they are
	much much harder to read with those extra parentheses.

9. DECLARE/PROCLAIM.
	Sure.

10. simple-vector
	Yes.
11. Flush RESET-FILL-POINTER, add FILL-POINTER.
	Sure.
12. :named keyword to make-array/make-simple-vector
	I will send this out separately.  It bothers me and leaves
	too many things unspecified.

13. Reintroduce *IBASE*...
	Yes, but *READ-BASE*.
14. sub-read
	I really don't care.  There is not really a problem with defining
	functions in pairs;  for instance, in NIL, we have
	(defun readline (&restv v)
	   (read-apply ':readline #'readline-raw v))
	(defun read (&restv v)
	  (read-apply ':read #'read-raw v))
	where read-raw and readline-raw are the simpler versions.
15. Propose that we rename *PRINfoo* to *PRINT-foo* for all foo...
	Yes.
16. floating-point in format...
	Probably the right thing to do.  I have not thought about it.
17. Eliminate MAXPREFIX and MAXSUFFIX,...
	Sure.
18. vertical bars around a symbol following : or #:
	We should definitely allow that.  For this, or in fact any
	pervasiveness attributable to a package prefix, one only needs
	to define the "token" as the characters up to and including the
	colon.  I do not believe that this is hard to implement.  As to
	whether the package name may be enclosed in vertical bars, or
	have funny hacks with case, really don't care, although i do think
	that this will be harder.

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.
	Yes.  I never did notice that this change had been introduced;
	certainly this kludge has never been supported in my lisp
	implementation.  Who is responsible for this N.I.L. system you
	mention which necessitates such grotesqueries?

20. APROPOS and PPRINT should return NIL...
	I like zero values, but don't particularly care about that or NIL.
21. *features*...
	Put them in the keyword package, and ensure that however the
	test after #+/#- is read, it works without colons.  (Whether
	this be interning them there initially, or doing package-independent
	comparison to test the features.)