Re: Another ballot

[Dir LCSR Comp Facility <HEDRICK@RUTGERS.ARPA>]

A1. Yes, do PARSE-INTEGER.  But no pound-signs or other hair, please.
A2. I think I am opposed to the details of the new PROCLAIM.  I agree
	with most of what is proposed, but I do not like the idea of an
	implicit EVAL-WHEN, at least if I understand what is meant. I
	would like PROCLAIM to be evaluated in exactly the same way as
	DEFUN.  That is, if you type it at the top level of Lisp, or it
	is at the top level of a file, it would work in the expected
	way.  As I understand it, you are proposing that a PROCLAIM
	could occur in a random place in the middle of code, and it
	would still happen at COMPILE or LOAD time.  I think this is a
	bad idea.  The whole idea of restricting DECLARE to the
	beginning of blocks was to minimize this kind of thing.
A3. We can live with anything that you can implement, but would prefer
	B, to treat the package part just like the symbol part.  MUCH
	easier for users to remember.
A4. Yes, fix VECTOR-PUSH and VECTOR-PUSH-EXTEND.
A5. No, we don't need more MV mechanisms.  As always, I propose to
	simply MV's further by removing them.
A6. No, I am satisfied with an almost-transportable DEFSTRUCT.
A7. No, do not remove SET.  While we are at it, CONS seems like an
	unnecessary relic.  It is after all a special case of a
	structure....
A8. No, do not make it an error to do (APPLY '(LAMBDA ...  That is,
	don't do just that.  However I agree completely that the whole
	issue of what is a function object needs further thought.  If
	a complete analysis of this results in (LAMBDA not being a
	function object and thus not allowing APPLY on it, I am willing
	to accept that.  I suspect that it is too late to do such an
	analysis for this release of Common Lisp.
A9. Abstain on VREF.
A10. Yes, allow a seed in MAKE-RANDOM-STATE.
A11. My concern with APPLYHOOK is whether we are ready to standardize
	that hook.  If all of the implementors and potential
	implementors agree that these are the right hooks, then
	by all means.  I defer to the Spice people on this, since we
	are using their evaluator.
A12. Yes, allow simple destructuring.  Do not destructure the family cat.
A13. No, do not make INTERN return multiple values.  I am willing to
	allow it for FIND-SYMBOL, however.
A14: Yes, that name seems reasonable.  Would you consider using
	MV-SETQ, etc.?  While I am just as happy to discourage the use
	of all MV primitives, do we really want primitives with names
	that are that long?
A15: In general I accept the proposal on bounds.  I think some
	implementations might be able to live with arrays with a small
	maximum rank.  However I do not believe that this is true for
	arguments for functions.  I agree that it is a pain to 
	implement large numbers of arguments for functions.  I know.
	It has caused us real hassles.  Nevertheless I believe it is
	necessary.  I am willing to let implementors cop out on
	array ranks if they want to, but not on arguments.  I believe
	that the only limits on number of arguments should be those
	imposed by the size of memory, stack space, etc.  It is bad
	enough to have arbitrary limits in Pascal.  In a language
	like Lisp it is unforgiveable.  We probably need to set an
	actual number as the minimum maximum number of arguments.  The
	number must be set large enough to make it impossible for
	an implementation to get away with any of the easy solutions,
	and small enough that we can still implement CLISP on a micro.
	By the way, would you allow us to set CALL-VALUES-LIMIT to 1?
A16.  OK, do what you want with MACRO.
A17. Yes, reduce all numbers to their simplest form (but not floating
	point to integers...)
-------