Let's Talk About Lambda Functions!

[Bryan Olson]

Paul Rubin wrote:

 > I don't see why the anti-lambda contingent doesn't want to also
 > get rid of anonymous scalar expressions.  I mean,
 >
 >    a = b + (c * d)

I don't think that's really a best example.  Functions and procedures
are supposed to be fist-class in Python.  We don't have to name lists,
tuples, or dictionaries, so why should we have to name procedures and
classes?  Python is supposed to be regular.

The inability to define procedures independently of their names is a
terrible wart.  It deceives people.  The requirement to "def" a
procedure to a name hides the fact that the procedure is truly a value,
and no more limited to standing by a name than is an integer.  Yes, it
is often (usually) useful to assign that value to one or more names; the
same may be said of lists and dictionaries.


I remember the time when I thought of lambda as weird, or "arcane".  I
was learning Lisp, and I had already studied the fundamentals of Basic,
Pascal, FORTRAN and C.  Now I see that the reason I found the lambda
difficult was because I was only familiar with languages in which
procedures are not first-class.  (Well, admittedly also because the
traditional term "lambda" didn't ring like other reserved words).  In
those other language, the name bound to an address to which the compiler
would put a jump.  Anonymous function were important to my understanding
of functions as values, and breaking of my FORTRAN-think.

We certainly don't want to re-enforce the false notion that functions
and procedures are special things with intrinsic names.  They may be
stored in a list as naturally as assigned to a name.  And yet "def
a[3](x): ..." doesn't parse.

Expand lambda, maybe rename it.  But do not eliminate it, because
anonymous functions and functions-as-values go hand-in-hand.


--Bryan