Suggested new lambda-list syntax

[Jon L White <JONL at MIT-MC>]

 From the very beginning, there have been several people around here 
who never really accepted the &-keyword format for lambda lists -- KMP 
in particular has long been agitating for the list-like format which
you have just suggested.   I more-or-less agree with MOON's comments 
reproduced below about the importance of keeping the present &OPTIONAL, 
&REST, and &AUX; since these are the most common cases, I'd hate to see 
their usage haired up even one iota.   And I tend to agree with Fahlman 
that the proposed *format* is not succinct enough to be a "real winner" 
(whereas &OPTIONAL, &REST and &AUX are);  but at least in the rare cases 
where such additional generality is desired by a programmer, his requirements 
should be met in an upwards-compatible way.

However, I will say in defense of your proposal that it appears to be 
fully upwards compatible, so that we needn't flush the existing syntax, 
at least for the "common" cases, in order to add the more general mechanisms.

  Date: 23 September 1981 20:28-EDT
  From: David A. Moon <MOON at MIT-MC>
    I think &OPTIONAL, &REST, &AUX, and &KEY are quite different from the other
    lambda-list keywords.  Those four keywords delimit boundaries between
    various sublists, which could have been written as separate lists except
    that that would be a mess.  Your proposal doesn't really apply sensibly to
    those four keywords.  For other ones like &QUOTE, &SPECIAL, etc. it would
    be an improvement.
    A separate point: I don't think it makes sense to complicate the syntax in
    order to get rid of the reserved words.  Reserved words in this context cause
    no harmful effects, whereas a syntax with more parentheses and more noise
    words would decrease readability, and in a very central, heavily-used part
    of the language too.

One other interesting benefit, should your proposal go thru, is that
destructuring could be put into the lambda syntax without needing to
decide whether one wants the data-directed destructuring, or the program
directed one -- there is plenty of room in the keyword space to select
either one.  Currently, MacLISP and NIL don't really have destructuring
for LAMBDAs (only for LET), and the LISPM has no destructuring yet; so 
there would be no incompatibility problem.  The MacLISP/NIL LET could
then produce an apropriate flavor of destructuring lambda, and an
alternative let, say PLET (for Program-directed-destructuring-LET) would
produce the other flavor.