ballot A

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

A1. Add parse-integer.
	Yes.
A2. Proclaim.
	Yes.
A3. [Package names]
	I could live with b or c.  I have no strong objection to either.
A4. vector-push arg order.
	Yes, fix it.
A5. Add KMP's (NTH-VALUE n form)
	No objection if it is zero origined.
A6. defstruct primitives
	I don't really care.  The proposal was to supply an alternative
	to named arrays, which i do not approve of in the white pages
	as a mechanism for defining typed objects.
A7. eliminate SET and FSET
	I am fairly neutral on this.
A8. (apply '(lambda ...) ...)
	It should either be invoked in a null lexical environment, or be
	totally illegal.  In NIL, I have experimented with it both being
	invoked in a null environment, and being invoked in the "current"
	environment.  The latter makes (mapcar '(lambda ...) ...) work
	as a Maclisp user might expect, but is totally ridiculous otherwise.
	Also, I do not see how it can be tractable to interpret it as if it
	were #'(lambda ...), because by the time you see it you have lost
	the context.
A9. Propose that we reinstate VREF.
	Shucks, i had just written documentation stating that this was
	obsolete.  I don't really care.  I would prefer to have primitives
	to access the simple array types.
A10. Add an optional integer seed to MAKE-RANDOM-STATE.
	Yes.
A11. Propose that we adopt the APPLYHOOK feture, as specified by Moon.
	Yes.
A12. Add a simple form of destructuring LET macro.
	Not as proposed.
	I would like a destructuring primitive which provides exactly
	the functionality defmacro provides, including &mumbles.  It
	should not be LET based; my experience with destructuring LET
	is that (besides grossness with LET*) the extra parentheses
	needed by LET syntax make it unreadable.  The NIL compiler defines
	(defmacro debind-args (pattern call-form &body body) ...).
	This is also used by the interpreter.
A13. A modification to INTERN and FIND-SYMBOL
	This sounds reasonable.
A14: Proposed by KMP that we rename MULTIPLE-VALUE to MULTIPLE-VALUE-SETQ.
	Can we shorten these to MV-SETQ and MV-BIND?  Instead of
	(multiple-value-setq (a b c) ...) it will be tempting to abbreviate to
	(setf (values a b c) ...), although i guess that is not supported.
A15: Implementation limits
	Yes we should have constants with the values of those limits,
	but No, we SHOULD specify certain minimums within which portable
	code may blithely run correctly.
A16. Guy proposes that we get rid of MACRO
	Yes, but (setf (macro-function ...) ...).
A17. Reduction to canonical form
	For rationals, yes, definitely.
	For the complex case i am not so sure.  I guess i will defer to
	others on this, but i feel uncomfortable with it.