Another Ballot

[Kent M. Pitman <KMP @ MIT-MC>]

A1  Yes	PARSE-INTEGER is OK.

A2  No	I prefer that declarations be special forms. I would prefer to offer 
	PROCLAIM with no argument evaluation and *PROCLAIM as a subr form
	such that	(PROCLAIM form1 form2 ...)	is the same as 
	(EVAL-WHEN (EVAL COMPILE LOAD) (*PROCLAIM 'form1 'form2 ...))
	That is, the subr form should not be "implicitly" in any EVAL-WHEN.
	I would like to keep the common, purely declarative, case simple.

A3  B	I strongly prefer B. I believe it to be maximally consistent with
	 the rest of the Common-Lisp design. I also believe that current
	 Lisp Users' models best support this view.
	I would also accept a hybrid B/C with syntax as per B, but with
	 case-insensitive lookup. I slightly prefer B to this, however.
	I believe C is just barely acceptable, but I think this will do
	 very bad things to users' models. Many users take a long time to
	 understand what |...| and / are about already; I believe trying to
	 separate contexts where they can be used will add undue conceptual
	 overhead for novices.
	I strongly oppose A as inconsistent with the case-retention rules for
	 the "other half" of symbols. I think novices would be confused silly
	 by this.

A4  Yes	Consistency between VECTOR-PUSH,etc. and PUSH sounds good.

A5  Yes	I like NTH-VALUE. NTH was zero based and people can live with that.
	I find such an argument spurious.

A6  ---	I have no strong feelings on this named structure primitives issue.

A7  Yes	I strongly support this. Users read too much into the symmetry of
	names SET and SETQ. In a lexical lisp, this is far more dangerous
	than a dynamic lisp. ALAN should just type (SETQ #.+ ...) to the
	read-eval-print loop.

A8  Yes	I think (APPLY '(LAMBDA ...) ...) should be left undefined and
	implementors might be free to support it as an implementation-
	dependent upward compatible extension. This will save implementors
	from having to take any immediate action, but leave Common Lisp
	more flexibility later on. Users should be discouraged from doing
	this.

A9  No  If SVREF exists, then VREF maybe should exist for symmetry; otherwise,
	it seems like SVREF should be SAREF instead ... Alternatively, SVREF
	could be renamed VREF. I'm not sure any more what the full proposal
	for arrays/vectors looks like any more. I'd rather defer this issue
	until I can evaluate it more coherently.

A10 Yes	Extra arg to MAKE-RANDOM-STATE sounds harmless and potentially useful.

A11 Yes	Just this week I found the APPLYHOOK feature in the LispM and was
	able to clean up some very ugly code which was trying to replace it.
	The phrase "EVAL binds both *EVALHOOK* and *APPLYHOOK* to NIL 
	around calls to either of them." has a very nebulous "them" referent.

A12 No	I like and use Destructuring LET a lot, but am sympathetic to peoples'
	arguments that it is a data abstraction violation in general. I do,
	however, agree with Weinreb's comments on DLET and suggest that he
	propose this DESTRUCTURING-BIND primitive as an alternative.

A13 Yes Flush FIND-EXTERNAL-SYMBOL in favor of FIND-SYMBOL with extra value.
	The extra value would be needed in any case to disambiguate the case
	of FIND-SYMBOL of "NIL" ...

A14 Yes	MULTIPLE-VALUE => MULTIPLE-VALUE-SETQ

A15 Yes	Add ARRAY-RANK-LIMIT, etc. Even if these were the same values 
	everywhere, having people compare to symbolic names would be good.

A16 No	This has certain SET/SETQ confusions about it that make me very
	uncomfortable. The issue of "scoped" macros doesn't now occur but
	might some day and I worry that if arg1 to SET-MACRO is ever anything
	besides 'something, it may be hard to statically resolve in a useful
	way. The minimal change that would make me happy is to call it 
	SETQ-MACRO or MACRO-SETQ or some such, but all in all, I'd rather
	just flush this proposal.

	MACRO has other problems (like it's a pain for  programs like ATSIGN
	and EMACS which may not realize it defines something). Why not just
	change its name to DEFINE-PRIMITIVE-MACRO. I think that would 
	adequately discourage its use by novices while not introducing the
	SET/SETQ problem I mentioned about above.

A17 ---	This sounds superficially like a good idea, but I have done no 
	significant programming in such areas so can't adequately evaluate
	the efficiency implications or the effect on the compiler of not 
	being able to predict an exact datatype returned from one of these
	functions (potentially important on general purpose hardware). So
	I'll abstain and hope you others know what you're doing.