LAMBDA syntax counter-proposal

[Daniel L. Weinreb <dlw at MIT-AI>]

I am much happier with GLS's new proposal than anything I have ever seen
before.  This format is very easy for a program to parse.  It is also
easy for people to read -- it is even less visually obnoxious than our
present format, whereas the more complex keyword-oriented proposals are
definitely more visually obnoxious.

I disagree with the philosophy put forth in EAK's recent mail -- I do
not think that it should be a goal that the format of the lambda list be
extensible.  I do not think that lambda lists are a place in which
creeping featurism should be allowed to fester.  We are talking here
about the basic foundation stones of the language.  This is not a place
to add random hair.  If you want hair, you can build it with macros, but
the macros should expand to code that does what you want, NOT into hairy
lambda lists with extra keywords and features.

As an example, I think that &aux variables are a bad thing.  We already
have several good syntaxes for letting you bind variables; &aux is now
completely superfluous.  &aux comes from CONNIVER, in the early days of
Maclisp.  Since then, LET has been installed, and it is far better for
this purpose.  &aux has outlived its usefulness and is obsolete.

I'm also inclined to retain rule 4; the need for the two-pass processing
seems semantically bad (and also looks hard to implement without an
efficiency loss in accessing the required arguments that are past the
optionals (since their stack location is no longer constant)).

I am strongly in favor of this proposal.