Memorial Day Ballot

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

Summary

 YES        on	1-2, 4, 7-16, 19, 21.
 NO         on	3, 6, 18, 20.
 no opinion on  5, 17.

Comments

 3. No	Do not add GET-INTERNAL-TIME and/or GET-REAL-TIME without 
	specifying the format of the time. My experience with
	code that hacks times says this is frequently worthless
	and often dangerous.  If the units are unspecified, code
	may appear to run while in fact producing bogus results.
	I might accept a modified proposal where these functions
	were keyworded and implementations could optionally signal
	an error for keywords they didn't handle. eg,
	(GET-INTERNAL-TIME :MILLISECONDS), etc.

 4. Yes	Constrain system-provided macros to not expand to 
	system-dependent special forms. Be careful to word this such
	that it's understood that system-dependent macros can be part
	of the expansion as long as those macros will eventually
	bottom out as system-independent special forms and/or 
	any kind of function(s).

 6. No	Actually, if NIL is allowed in place of any variable to be bound or
	set meaning IGNORE, I support the proposal. In the absence of such
	a restriction, I am swayed by Steele's comments about irregularity.
	Maclisp gets much power from allowing NIL in some forms to mean an
	ignored argument, but programs which transform code suffer problems
	of irregularity in what can go in which binding lists.

 7. Yes	In fact, if Common Lisp had primitives for creating and
	manipulating processes, I would claim that CATCH-ALL and
	UNWIND-ALL in some form might be needed. Perhaps, too, if
	it specified the implementation of debuggers, complex
	error handlers, etc. In the absence of such, however, I
	have seen no valid applications for such primitives. Many internal
	facilities will be implemented with CATCH/THROW and users will not
	be able to recognize what kinds of tags do what things in order to
	not screw themselves or thwart important system functionality.
	Something like CATCH-ALL or UNWIND-ALL may be needed internally by 
	a given implementation, but since each implementation will almost
	surely use it differently, no attempt should be made to export
	or standardize this feature at this time.

 8. Yes	This is quite useful. Many people prefer destructuring to
	&keywords. I recommend, in fact, allowing (DEFMACRO FOO (A . B) ...)
	to mean (DEFMACRO FOO (A &REST B) ...) and even
	(DEFMACRO FOO X  ...) to mean (DEFMACRO FOO (&REST X) ...)
	as I'm pretty sure the Maclisp family now allows. Maclisp even allows
	(DEFMACRO FOO (&OPTIONAL ((FOO . BAR) '(A . B)) ...) ...)
	to work. This, too, can be useful. Then the restriction 
	wouldn't be "left of &" but would rather be "any place that
	is unambiguously reserved for variable names" or some such.

 9. Yes	This sounds harmless and might do some good.

10. Yes	I probably agree with all this. A picture of the type hierarchy this
	proposes would be helpful so I'd feel more sure.

12. Yes	I dispute the claim that DEFSTRUCT can't already work in a site-
	independent way. You could put a unique marker in slot0 of the
	defstruct (eg, a gensym whose plist pointed at the real name of the
	structure (which would in turn point back at the gensym)). However,
	having a primitive named-array facility of some sort would be fine
	also.

15. Yes	With regard to *PRINT-READABLY*, etc., the manual should give 
	explicit advice to users saying that they must test this flag 
	when writing print methods for things that print with #<...>, 
	otherwise this flag will be of less value.

16. Yes	The change to ~G breaks a lot of code, but I suppose the eventual
	result is for the better. It will certainly ease the chore of
	mechanical translation.

18. No	I would like to see a more coherent description of what this means
	before I say yes. In general this sounds right, but I'm increasingly
	bothered by the off-and-on way we seem to treat package prefixes as
	either strings or symbols. There's an argument that says "...", not
	|...| should be what's allowed. There are also reasons for believing
	|...|:FOO should denote package "/|.../|":FOO, etc. -- at least, under
	this vague proposal. I will probably vote yes on this eventually when
	a complete, coherent proposal is made.

19. Yes	Both styles are occasionally useful, but the only thing you can
	usually guarantee the correctness of is the toplevel case. ~:A and
	~:S should not be pervasive.

20. No	The return value should be left undefined and implementors should
	be encouraged not to return anything `big'. On the LispM, it works
	well for these sorts of things to return 0 values, since they then
	don't clobber the value of "*", and one can do things like
	(GET 'FOO 'BAR)
	(GPRINT *)	;GPRINT is a pretty printer
	(CAR *)		;refers to (CAR (GET 'FOO 'BAR))
	If GPRINT returned NIL, * would be clobbered with a useless value.

	Specifying that these functions return no values and specifying that
	this feature of the read-eval-print-loop happens might be a win.

21. Yes	This problem may be more general than just FEATURES, but this is a 
	good start.