Issue: LAMBDA-FORM (Version 3)

[Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>]

Ok, I just modified the benefits, aesthetics, and discussion to
reflect Masinter's concerns that this would make for two ways to
do the same thing. Hopefully this just makes the writeup more
fair and doesn't change anyone's vote. -kmp

-----
Issue:        LAMBDA-FORM
References:   LAMBDA (p59)
Category:     ADDITION
Edit history: 22-Jun-88, Version 1 by Pitman
	      16-Sep-88, Version 2 by Pitman
	      02-Oct-88, Version 3 by Pitman
Status:	      For Internal Discussion

Problem Description:

  In Scheme, one writes not #'(LAMBDA ...) 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.]

Proposal (LAMBDA-FORM:NEW-MACRO):

  Add a LAMBDA macro, which has equivalent effect to:

    (DEFMACRO LAMBDA (BVL &REST BODY) `#'(LAMBDA ,BVL ,@BODY))

Rationale:

 This is an upward-compatible extension which ``codifies current
 practice'' in that it makes a commonly defined macro available
 as a standard part of the language.

Test Case:

  #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)))

Current Practice:

  Symbolics Genera implements 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!]

Cost to Implementors:

  The cost is trivial. A portable definition is shown in the
  problem description above.

Cost to Users:

  None. This change is basically upward compatible.

Cost of Non-Adoption:

  There are no really major consequences of non-adoption.

Benefits:

  It's been suggested that some people write '(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.

Aesthetics:

  Some people believe that this makes two different ways to get
  essentially the same functionality, and so it clutters the language.

  On the other hand, 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.

Discussion:

  Numerous people have suggested this from time to time in the past,
  but it's often been amidst a bunch of other more controversial issues.
  Pitman wrote up this proposal and supports 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 addresses this issue.

  An earlier revision of this proposal considered the alternative of
  making this a new special form, but most people seemed to prefer the
  simpler alternative of just making it a macro for now.