Memorial Day Ballot: comments on other people's entries

[David A. Moon <Moon%SCRC-TENEX%MIT-MC@SU-DSN>]

    Date: Tuesday, 31 May 1983, 12:35-PDT
    From: BENSON at SPA-NIMBUS
    6. No.  NIL already has too much attached to it.  A decent compiler will
       detect variables which are set but not used.  It's not important
       enough to add another "keyword" usage to NIL.

The issue here is the difference between (MULTIPLE-VALUE (NIL X) (FOO))
and (LET (TEM) (MULTIPLE-VALUE (TEM X) (FOO))).  In other words it's not
an attempt to get increased efficiency, but an attempt to increase clarity
by avoiding the need to introduce unnecessary "fake" variables.  It's not
a big deal but I thought an explanation might be helpful.

    14. No.  I don't think the user needs to be concerned with whether a
	call to READ is at top level or not, since READ has to use a
	special variable to keep track of its state.

The issue is how do you know when to re-bind this special variable?  What
if a reader macro, while reading from a file, asks for some input from the
terminal for some reason?  What if the same reader macro does the same thing
while reading from the terminal?  What if the reason it asked for input wasn't
that it was programmed to, but that it got an error?  READ can't tell whether
it was called with the intent of being a recursive call or the intent of being
a top-level call, although there are ways it can guess that work a lot of
the time.

    21. Put them in the GLOBAL (excuse me, LISP) package, instead of
	KEYWORD.  Otherwise, users will be typing #+:FOO.
Of course if the things in *FEATURES* are required to be keywords then
the #+ and #- macros will read in the keyword package or use string-equal or
otherwise arrange for you not to have to type a colon every time.

							   Actually, there's
	no need to specify.  One ought to be able to push any symbol onto
	*FEATURES*.  The object after #+ and #- should be read just like any
	other.  Remember, it can be a list, too.

This is a reasonable position.  In other words, MACSYMA:INTEGRATION and
CIVIL-RIGHTS:INTEGRATION could be two different features from two different
packages, that you might want to test for separately.  Saying that features should
be keywords, i.e. that packages lead to too much complexity here, is a reasonable
position, also.  The Lisp machine does the latter currently, but that doesn't
mean much.  I'm still neutral.  But I'm not sure everyone has seen the
point of both sides.

    Date: 31 May 1983 1201-PDT
    From: Dave Dyer       <DDYER@USC-ISIB>

    7. Flush CATCH-ALL, UNWIND-ALL	    NO!  Otherwise there is no way to escape
					the predefined error semantics.  These
					provide the essential gross hook that
					allows implementation of whatever variant
					is necessary.  Example: The oly kind of
					CATCH Interlisp HAS is effectively
					CATCH-ALL
Conditions are not throws.  I think Fahlman sent a message in the past few days
that explained this pretty well.  I'll be proposing a condition system for Common
Lisp in a few weeks (which could stretch into months, of course).

    20. APROPOS, PPRINT return NIL	    Ok. Rather than a separate family to 
					specify type of results, 
					I'd prefer an optional argument to specify
					what to do.  I usually use
					    NIL->PRINT
					    T-> return list
					     otherwise (APPLY* X --) and
						    return list of non-nil results

This seems like a good idea, at least for APROPOS.  Better than
introducing a new function.  Both APROPOS and PPRINT already take an
optional argument, so they may need to be converted to keywords.  The
default should be to print out and return nothing.

    Date: 31 MAY 83 02:35 PDT
    From: JONL.PA@PARC-MAXC.ARPA

    Why "but ..."
      5 - What about functions that don't pass their keylist on; e.g.
	  MAKE-ARRAY ?  Is it really true that  :allow-other-keys  will
	  have the proposed meaning in *every* keyword-taking function?
Yes.  What if someone passes his keylist on -to- MAKE-ARRAY?

    Spread Uniformity:
	The meaning of a lambda-list for DEFUN, for lambda forms, and
    for DEFMACRO ought to be perceptually the same

I am in very strong disagreement with this.  Functions and special forms
are fundamentally different.  "Destructuring" in the lambda list of a
function refers to taking apart THE VALUE OF AN ARGUMENT AT RUN TIME.
"Destructuring" in the "lambda" list of a macro refers to taking apart
THE SYNTACTIC STRUCTURE OF THE INVOKING FORM AT COMPILE TIME.  These are
as different as can be.  Beginners have enough trouble understanding
this without our throwing additional roadblocks in their way.

	Especially is this matter of uniformity important for auto-documentation.
   Wouldn't it be nice if you could write
	(DEFUN FOO ((A B) C) ...)
    rather than
	(DEFUN FOO (L C) (PROG ((A (CAR L)) (B (CADR L))) ...))
    so that ?= type of helpers would show you more about the syntax
    of input arguments?  
What if I wanted to say that L was a list and C was an integer?  What
if I wanted to say that the first argument was a date and the second
argument was a string which was the name of someone on the Common Lisp
mailing list?

	What a loss if such facility worked for DEFUN definitions, but 
    not for DEFMACRO definitions (and vice-versa)!
Of course you can always get the auto-documentation to say anything
you like, by using (DECLARE (ARGLIST ...)), at least on the Lisp machine.