[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Suggested new lambda-list syntax
- To: rms at MIT-AI
- Subject: Suggested new lambda-list syntax
- From: Jon L White <JONL at MIT-MC>
- Date: Fri ,25 Sep 81 20:06:00 EDT
- Cc: MOON at MIT-MC, LISP-FORUM 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 "E, &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.