LAMBDA-FORMLAMBDA ...) but just (LAMBDA ...).
Many Common Lisp programmers have asked for this feature. It can be written by the user, but since it's a commonly asked for feature, it would make sense for it to be in the standard.
Also, even though the definition is trivial,
(DEFMACRO LAMBDA (BVL &REST BODY) `#'(LAMBDA ,BVL ,@BODY))
it is difficult to offer this as an extension because then "portable code" tries to define it, it will get a redefinition warning because it will be clobbering the system's predefined definition. [An implementation could shadow LAMBDA, but that, too, has associated problems.]
LAMBDA macro, which has equivalent effect to:
(DEFMACRO LAMBDA (BVL &REST BODY) `#'(LAMBDA ,BVL ,@BODY))
#1: (DEFUN ADDER (N) (LAMBDA (X) (+ X N)))
(FUNCALL (ADDER 5) 3) => 8
#2: (MAPCAR (LAMBDA (X) (+ X 3)) '(1 2 3)) => (4 5 6)
#3: (MACROEXPAND '(LAMBDA (X) (+ X Y)))
=> (FUNCTION (LAMBDA (X) (+ X Y)))
NEW-MACRO.
Symbolics Cloe does not offer a LAMBDA macro because users who defined their own in portable code complained that they were getting redefinition warnings that CLtL had led them to believe shouldn't happen. [Ironically, the redefinition warnings always came when they tried to define LAMBDA in the way it was already defined!]
Many other Common Lisp implementations do not offer such a macro.
LAMBDA ...) rather than #'(LAMBDA ...) because it's less ugly, and then run into confusion later. If they could just write (LAMBDA ...), some that use overly superficial reasons for the choice of one notation over another might accidentally select the primitive they should probably really be using.CL, however, the operator is not evaluated in the same way that the operands are. This definition of LAMBDA as a macro would obscure this difference. A novice Lisp programmer might have a hard time understanding why the #' is optional in
(MAP [#'](LAMBDA (POINT) (+ (POINT-X POINT) (POINT-Y POINT))) POINT-LIST)
but is required in (MAP #'SUM-OF-COORDS POINT-LIST)
This proposal "clutters" the language because it makes the syntax more complex. LAMBDA is then used not only as a "flag" for introducing lambda-expressions, but also is a macro which generates functions. There is at least one precedent for having two operations that do the identical thing -- NOT and NULL. Both have been retained because they express different intents. In this case, the intent of #'xxx might be to ``access'' a function by name (the name of an anoymous function being its lambda expression), and the intent of (LAMBDA ...) is to ``create'' a function. This distinction is subtle but may be expressionally interesting to some programmers in some situations.
Notationally, some people believe strongly that (LAMBDA ...) looks a lot better than #'(LAMBDA ...). Certainly it takes up fewer characters, and (LAMBDA ...) is a notable offender in code needing to be split onto multiple lines, so every little bit probably helps.
LAMBDA-FORM:NEW-MACRO.
Technically, CLtL does already permit implementations to predefine a LAMBDA macro, but most argue that this leeway was accidental. CLtL says that "all" functions, etc in CLtL must be in the LISP package, but it does not say "all and only". This oversight leaves enough room for implementors to add all manner of extra junk in the LISP package. A separate cleanup item (LISP-SYMBOL-REDEFINITION) addresses this issue.
An earlier revision of this proposal considered the alternative of making this a new special form. Many people prefered that alternative. However, there were also strong objections to requiring a new special form; since the FUNCTION special form is still necessary (for #'symbol), it was deemed better to have LAMBDA a macro which is defined in terms of FUNCTION than to have both LAMBDA and FUNCTION as special forms.