[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Issue: LAMBDA-FORM (Version 2)

    Date: 16 Sep 88 02:40 PDT
    From: masinter.pa@Xerox.COM

    I think this issue needs only minor patches...

    I guess we should come out with NEW-MACRO and mention in the discussion that we
    considered NEW-SPECIAL-FORM.

    Other opinions?

I concur.

Here's a proposed rewrite. I took care of Walter's concern about the
"technicality" alluded to at one point in the current practice by moving
it to the discussion and expanding it.

Issue:        LAMBDA-FORM
References:   LAMBDA (p59)
Category:     ADDITION
Edit history: 22-Jun-88, Version 1 by Pitman
	      16-Sep-88, Version 2 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,


  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


  Add a LAMBDA macro, which has equivalent effect to:



 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.


  Improved aesthetics.

  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.


  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 helps.


  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.