Holiday Ballot

[JONL.PA@PARC-MAXC.ARPA]

Summary:
   YES          -- 2,4,7,14,16,18
   YES, but ... -- 5,6,8
   NO           -- 9,17,20
   No comment on remainder

Why "NO":
  9 - PROCLAIM is still unnecessary -- our discussions showed that
      it is a trivial matter of programming for Evaluator, Compiler,
      and code analyzers to detect the DECLARE as a syntactic part
      of a binding context (e.g., LAMBDA or PROG).  Do we need more
      ways to do the same thing just because some system implementor
      couldn't think of how to do this S.M.O.P.? (Small Matter Of ...)
 17 - There are two completely independent items here, and they should
      *not* be bundled into one ballot question.  Eliminating the 
      redundant MAXmumbles hardly needs a ballot, since it has been
      in the mails and no one seems to object to their demise.
 20 - I think the 0-return-values solution is better.


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?
  6 - I like KMP's arguments; the issue is one of uniformity. See
      the note "Spread Uniformity" below.  Focusing on MULTIPLE-VALUE
      is far to limited a perspective -- I'd prefer this were extended
      to all LAMBDA position, just like MacLisp.
  8 - Same comments as for 6.
 

Additional comments on "YES"
  2 - Is this actually a change from the current implementation of LOOP?
      I wonder, why wasn't RPG's suggestion about the MAP series of functions
      added to the ballot here; it would imply a somewhat incompatible change
      the way MAP etc are implemented in MacLisp, and as such is certainly
      deserving of a place on the ballot.
 14 - I've written a number of readers in Lisp, and found the SUB-READ
      functionality just the thing for improving efficiency of macro
      characters (and similar things in the # repetoire).   Upon entry to
      READ, a number of items may be checked for consistency, and some
      particular values may want to be "cached" in global variables;  there
      is no reason for the recursive-entries to do this.


Spread Uniformity:
    The meaning of a lambda-list for DEFUN, for lambda forms, and
for DEFMACRO ought to be perceptually the same, namely it represents
a way to take a sequence/list of items and "spread" them out into
"slots".  Historically, these slots were non-NIL symbols; in late
1978, MacLisp (and later NIL) extended the notion of "slot" to admit
NIL, meaning "ignore", and any descendable S-expression, meaning
"destructure" the item spread into this slot.  The competitor to this
plan was the "Program-oriented destructuring"; although it has some
good points, it seems to have dropped out of view during the past several
years 
    In case you don't remember, the "Data-oriented" version says
that the "slot" is a pattern whose non-NIL leaves are symbols to be
bound to the corresponding value selected from the data item; the
"Program-oriented version" says that the "slot" is a program which
would build up the data item if all its accessor parts had the
right value.  Example
    (LET (((A B) X)) ...)           ;Data, or pattern, oriented
    (LET ((`(LIST ,A ,B) X)) ...)   ;Program oriented version
both would bind A to (CAR X) and B to (CADR X).
Note that the Data-oriented version is not limited to lists:
    (LET ((#(A (B . #(C D)) F) X)) ...)
But the "Program-oriented version is even more general:
    (LET ((`(GET ,B 'MUMBLE) X)) ...)
That is, it would be possible to indicating a binding to *any*
LOCFable place, and not just to symbol values.  [Apologies if I've 
mistated the format, or capabilities of the "Program-oriented version",
but I don't think the actual details matter that much]
   The point of bringing all this up again is that to "fix" one of
the places that does "spreading" and not "fix" the other places
correspondingly is to perpretate a fairly gross and pointless
inconsistency.  [MacLisp failed to generalize SETQ, but instead provided
the macro DESETQ; as it turned out, all the "destructuring" was done
essentially by macro-expansions which used very primitive operations.]
    Especially is this matter of uniformity important for auto-documentation.
Interlisp has an extremely useful capability in its reader -- the ?= 
macro -- which access the argument list of the function you are about
to type arguments to; e.g., typing
   (CONS 3 ?=
causes the informative typeout
   (CONS CarArgumentName = 3
         CdrArgumentName )
so that you can see the names in the lambda list. (actually, the 
argument names for CONS are typically X and Y, but witht he use of
SMARTARGLIST . . . ).   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 a loss if such facility worked for DEFUN definitions, but 
not for DEFMACRO definitions (and vice-versa)!