lambda-cleanup

[Michael J. Beckerle <BECKERLE@XX.LCS.MIT.EDU>]

Issue:		LAMBDA-IS-OPERATOR
References:     X3J13/86-010, x3j13/86-019 pg 4.
Category: 	Compatible Change
Edit History:   v0 28june88  mike beckerle


Problem Description:

The symbol LAMBDA in common lisp has odd status.  It is not an
operator of any kind, but is recognized by other forms, like
FUNCTION, as a syntactic construct indicating that an expression
represents a function.

One must write (FUNCTION (LAMBDA ...)) or #'(LAMBDA ...)
to indicate an anonymous function in common lisp, where 
simply (LAMBDA ...) would be just as clear.

The proposal FUNCTION-TYPE passed in June 88 by x3j13 takes
significant steps to help clarify the difference between functions,
and lists which "look" like functions. LAMBDA-NON-OPERATOR goes
further in this direction.


Proposal: LAMBDA-IS-SPECIAL-FORM

LAMBDA should be a special form which denotes a function.

In the light of the FUNCTION-TYPE proposal, this means that
lambda-expressions would denote objects of type FUNCTION, and that
quoted lambda expressions would denote objects of type LIST. 

Proposal: LAMBDA-IS-MACRO

Define lambda as a standard macro as follows:

(defmacro lambda (&rest body)
  `(function (lambda ,@body)))


Discussion: 

One of the most confusing aspects of lisp for naive users is the
confusion in lisp between "meta" programming, and "higher-order"
programming. By meta programs I intend programs which manipulate the
lists which are the syntax of other programs; for example, macros are
usually "meta" programs.  Higher-order programs, on the other hand,
are programs which accept functions as arguments and return functions
as results. 

Since meta-programming and higher-order programming are really
orthogonal techniques, it is better to avoid confusing the two.
Particularly since both are difficult programming techniques.

The key characteristic of meta-programming in lisp is use of QUOTE,
quoted expressions, list manipulation, and either explicit or
implicit use of the lisp interpreter, EVAL, (or the compiler).
Higher-order programming does not involve the distinction between
programs and lists that look like programs, hence, whether EVAL is
called or not is irrelevant.  Higher-order programming is currently
confused with meta-programming by many lisp programmers. This cleanup
taken with the FUNCTION-TYPE cleanup would make the distinction much
clearer; hence, make learning and understanding common-lisp programs
easier.


If LAMBDA-IS-SPECIAL-FORM was adopted, then one can explain the
FUNCTION special-form primarily as a way of distinguishing between
the function and value definitions of a variable. It also allows
(FUNCTION (LAMBDA ...)) to be equivalent to (LAMBDA ...) for backward
compatibility. For LAMBDA-IS-MACRO, explaining LAMBDA in terms of
(FUNCTION (LAMBDA ...)) seems conceptually less simple.  Note that
accepting LAMBDA-IS-SPECIAL-FORM still allows all implementations to
define it using the macro definition if they wish.

Note that this change is orthogonal to any changes made to the
language to support '(lambda (...) ...) as an argument to funcall,
apply, etc. This was the subject of much debate when the
FUNCTION-TYPE proposal was considered at the June 88 x3j13 meeting.
Hence, if FUNCTION-TYPE is ammended to allow some common lisp
operations to accept lists and coerce them to functions, 
the LAMBDA-IS-OPERATOR proposal would be unaffected.

Implementation Impact:

LAMBDA-SPECIAL-FORM would require very minor changes to any programs
which have code-walkers.

Some implementations do not allow LAMBDA to be defined as a macro.
These implementations are already not in conformance with CLtL.



-------